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Eco System; 

& Internet Commerce 

Architecture 

Robust electronic commerce will require several proprietary systems to 

EEiteroperate. Commerceiyet is proposing a framework of frameworks that 
will bridge among conflicting platform requirements. 
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The Internet is revolutionizing cc 
vides tlie first affordable and secure way to link 
people and computers spontaneously across 
organizational boundaries. This is spawning numer- 
ous innovative enterprises — virtual companies, mar- 
kets, and trading communities. 

But the Internet's potential is imperiled by the ris- 
ing specter of digital anarchy: closed markets that 
cannot use each otlier's services; incompatible appli- 
cations and frameworks that cannot interoperate or 
build upon each other; and an array of security and 
payment options Uiat confuses consumers. 

One solution to tliese problems is an object- 
oriented architectural fi'amework for Internet com- 
merce. Several major vendors of electronic-conmerce 
solutions have announced proprietary versions of 
such a framework. The major platforms are 

• IBM CommercePoint 

• Microsoft Internet Commerce Framework 

• Netscape ONE (Open Network Environment) 

• Oracle NCA (Network Computing Archi- 

• Sun/Javasoft JECF (Java Electronic Commerce 
Framework). 

Recently, four of these companies have agreed to 
support a common distilbuted object model based 
on CORBA HOP (Common Object Request Broker 
Architecture Internet InterORB Protocol). Yet for 
commerce on the Internet to thrive, such systems 
must also interoperate at a business application level. 
(For more information see the "Major E-Commerce 
Platforms" sidebar.) A consumer or business using 
one framework should be able to shop for, purchase, 
and pay for goods and services offered on a different 
framework. This is currently not possible. 

In response, ConimerceNet is organizing Eco 
System, a cross-industry effort to build a framework 



of frameworks, involving both e-commerce vendor; 
and end users. This project is challenging from ; 
technical perspective because information technol- 
ogy is moving so fast that there's seldom t: 
even de facto standards to emerge. Instead, v 
deal with de facto interoperation — making 
patible products already in the marketplac 
municate. Our philosophy is simple; Protocols, 
formats, and the like should not hinder business. 

The success of tills process clearly depends on mar- 
ket leaders in each area participating actively on flieir 
respective task forces. Admittedly, in past battles for 
market dominance (such as in operating systems and 
desktop PCs), it was difficult to bring leading play- 
ers to the table. For robust Internet commerce, how- 
ever, interoperability is so fundamental that we have 
to turn the concept of openness on its head — it's not 
just publishing an API. Everyone's software has to 
work togetiier because no single company can con- 
trol what platform 



OVERVIEW 

As proposed, Eco System will consist of an exten- 
sible object-oriented framework (class libraries, 
application programming interfaces, and shared ser- 
vices) from which developers can assemble applica- 
tions quickly from existing components. These 
applications could subsequently be reused in other 
applications. 

We are also developing a Common Business 
Language (CBL) that lets application agents com- 
municate using messages and objects that model 
communications in the real business world. A net- 
work sendees architecture (protocols, APIs, and data 
formats) will insulate application agents from each 
other and from platform dependencies, wliUe facil- 
itating their interoperation. 

Functionally, Eco System fills three distinct roles. 
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• a layer of middleware that facilitates agent Inter- 
operation through services such as authentica- 
tion, billing, payment, and directories; 

• an object-oriented development 
that encourages the reuse of e-commerce mod- 
ules (even modules that represent the prod; 
line of an entire company) ; and 

• an Industry roadmap and Interoperability exa 
pie that promotes open standards and helps tech- 
nology vendors communicate with end users 
about product features. 

A framework of frameworks 

In object-oriented parlance, a framework Is an 
almost complete application that users can customize 
or extend to address particular needs. Eco System Is a 
framework for building Internet markets. Specifically, 
it's a framework of frameworks that model key busi- 
ness processes and services. Because frameworks build 
on each other, the resulting applications are tightly 
linked through a shared-services infrastructure. Eco 
System's frameworks faU Into four general categories, 
as Figure 1 shows. 



Business services 



Commerce services 



Network services 



• I-market services are those that serve an Internet 
market. These are vertical markets of closely 
aligned businesses. Examples are real estate (title 
search, loan, and escrow services), securities trad- 
ing (buy, sell, and quote services) , or any vertical 
supply chain ("solicit bid," "Issue request for 
quote," and "Issue purchase order" services). 

• Business services include generic business 
processes and applications common to multiple 
I-markets. These include retail (shopping, order 
fulfillment, and shipping) and buslness-to-busl- 
ness (procurement, order entry, inventory and 
supply chain management, and logistics) func- 
tions. Vendors may have initially developed such 
services for a specific l-market and later general- 



Figure 1. Four 
general categories 
of Eco System 
frameworks. 



Major E-Commerce Platforms 

IBM's CommercePolnt, a suite of e- 
commerce services, attempts to provide 
end-to-end business solutions (http://wvw. 
internet.ibm.com/commercepoint). It In- 
cludes software packages for electronic 
storefronts (Including credit card transac- 
tions using SET and bac](^-ofBce functions) , 
purchasing (requests for proposals, elec- 
tronic data Interchange, and bidding) , and 
distribution. 

Netscape ONE (Open Network En- 
vironment) is a platform-independent, net- 
work-centric application development 
environment based on publicly defined 
open standards (http://home.netscape.com/ 
comprod/one/whlte_paperhtail) . Key tech- 
nologies include HTML, Java and 
JavaScript 1.1, CORBA HOP, and broad 
support for open communication and col- 
laboration protocols (HTTP, NNTP, 
SMTP, 1MAP4, and POPS) and security 
services (Secure Sockets Layer 3.0 and 
X.509v3). Applications interact through 
these Interfaces (available on Netscape 
clients and servers), eliminating the sharp 
distinction between client- and server-side 
development. 

Oracle's Network Computing Archi- 



tecture (NCA) combines Web technology 
(HTTP and HTML) with CORBA 2.0 and 
HOP to provide distributed computing in a 
networked environment, NCA also sup- 
ports ActiveX/COM clients through open 
COM/CORBA interoperability specifica- 
tions ratified by the Object Management 
Group. Key components include "plug- 
gable" objects called cartridges that use IDL 
to identify themselves to other objects in a 
distributed system (see http://wwfw,oracle. 
com/nca/html/nca_wp.html) . 

Sun and JavaSoft's Java Electronic 
Commerce Framework (JECF) is an open 
platform for purchasing, banking, and 
finance (http://wwwjavasoft.com/products 
/commerce) . It provides a user interface (or 
wallet) for online purchasing and other 
financial transactions; a secure, encrypted 
wallet database; access to strong cryptog- 
raphy; applets; and a purchasing infra- 
structure. Java Cassettes implement specific 
online transaction protocols such as SET, 
Mondex, and CyberCash CyberCoin. 

These four vendors announced this 
March that they would redesign tlieir net- 
working products to support CORBA, 
Moreover, they promised to deliver some 
of these CORBA-compliant versions as 
early as this month. They are also expected 



to endorse the use of Java Beans, a plat- 
form-independent, component-based soft- 
ware architecture based on Java (see http:// 
splashjavasoft.com/beans/WhltePaper. 
html). 

This leaves Microsoft, which uses its 
proprietary Distributed Component 
Object Model (DCOM) architecture, as 
the major non-CORBA-compliant hold- 
out. DCOM is an OLE derivative for net- 
works, which runs only on Windows and 
also uses Microsoft's proprietary ActiveX 
components. These technologies support 
Merchant Server, a Microsoft product that 
allows Internet service providers to offer 
electronic storefronts supporting SET for 
about $3,500 (see http://www.microsoft. 
com/merchant) . Industry observers point 
out that Microsoft recentiy endorsed a 
Hewlett-Packard proposal to bridge the 
ActiveX and CORBA object models. 

Although the companies supporting 
CORBA are ConimerceNet members, 
Microsoft is not. This situation — in which 
the major market shareholder fails to par- 
ticipate — is common to similar industry 
consortium efforts. As CommerceNet's 
interoperability initiatives gain momentum, 
we hope that Microsoft will become an 
active participant. 
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Table 1. Sample service 
request messages. 



Service Message 


Payment 


Make a payment 




Obtain payment 








Have 1 been paid yet? 


Shipping 


Schedule a shipment 
Check the status 
Get a quote 



Perform a search 
Add, delete, or modify 



Get quote 
Schedule pickup - 
Pay 



Send invoice 
Payment enclosed 



Use SET 
Use E-cash 



JEPI framework 



>- [Tcash I 
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Figure 2. Frameworks 
communicate among 
themselves via NSIs 



ized them for reuse. Marketware Is a special sub- 
class of these services that links buyers to sellers. 
(Seethe "Marketware" sidebar) 

• Commerce services are basic e-commerce services, 
such as digital "wallets," that allow Individuals 
and companies to authenticate their identities, 
make payments, locate vendors, collaborate, and 
otherwise participate in an I-market. Advanced, 
next-generation commerce services will include 
secure multimedia mail, smart-card-based secu- 
rity and payment, digital-content delivery, appli- 
cation billing and accounting, 
management, and agent management. 

• Network services enhance the perfc 
ability, and security of the Internet 
date mission-critical business needs. Exampl( 



Include quality-of-service management, IP 
(Internet Protocol) multicast, delivery receipts, 
authenticated packets, and smart firewalls (those 
that pass packets only among authorized busi- 
ness partners) . 

Each framework specifies core services that all appli- 
cation objects belonging to that class (for example, 
payments and catalogs) must provide. They must also 
specify a network services interface (NSI) . An NSI is a 
set of messages In an Implementation-Independent lan- 
guage (CORBA IDL, Interface Definition Language) . 
These standard messages request services over a net- 
work and differ from APIs in that they are at a higher 
level and written in IDL. In addition, a framework 
must specify APIs for software modules involved in 
delivering services. 

Services 

Every application under Eco System — whether a 
catalog or an entire I-market — is a network-accessi- 
ble service. Table 1 illustrates a few core services pro- 
vided by three representative frameworks. The table 
lists paraphrasings of the NSI messages used to 
request the core services. These core services literally 
define what it means to be, for example, a payment, 
shipping, or catalog service. Vendors will differenti- 
ate their products by providing additional services 
beyond those specified in the framework. But the 
defining characteristic of a payment, shipping, or cat- 
alog object is Its ability to respond to the minimal set 
of core service requests specified in the associated 
framework. 

Modules can plug into frameworks via APIs; thus, 
some frameworks function as middleware, allowing 
access to several vendors' modules through a com- 
mon set of requests. Object wrappers transform stand- 
alone and legacy applications (written before a 
relevant Eco service framework existed) into Eco ser- 
vices. Application modules plug into e-commerce plat- 
forms via APIs, and other applications can access them 
using standard NSI requests. The JEPI framework is 
an example of a payment platform. When fully devel- 
oped, it will define standard APIs and protocols that 
allow interoperability of many Incompatible payment 
solutions already on the market. 

Figure 2 illustrates the hierarchical relationship of 
frameworks and the roles of NSIs and APIs. 

GETTING FRAMEWORKS TO TALK 

We are basing Eco System on CORBA 2.0, an 
emerging industry standard for distributed objects and 
networking. CORBA 2.0 includes the Internet 
InterORB Protocol (HOP), which Netscape 
Communicator will support. Eco will also work with 
HTTP (hypertext transfer protocol), HTML (hyper- 
text markup language), and Java. Figure 3 shows the 
Web-based architecture. 

The following design decisions conform to emerg- 
ing industry trends: 
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Marketware 

A special class of Eco applications and 
services brings together buyers and sellers. 
Marketware is based on a common plat- 
form tfiat developers can customize by 
plugging in different application modules. 
These modules serve as building blocks to 
implement a variety of value-added mar- 
kets and market services: 

• Matchmaking is a trading post where 
buyers and sellers can exchange goods 
or services. This service matches buy- 
ers and sellers on the basis of product 
descriptions and personal or company 
profiles (like, for example, Sun's 
Matchmaker). 

• Negotiation services allow buyers and 
sellers to post offers specifying price 
ranges, quantities, delivery dates, and 
other terms. The service notifies par- 
ties in real time or via e-mail of close 
matches. Parties can respond by mod- 
ifying their offers if so desired (as in, 
for example, the FastParts system). 

• Buy-sell brokering allows buyers to 
post requests for quotations, which the 
service forwards to registered sellers 
with appropriate interest profiles. 



Sellers can respond with bids, which 
the service collects, sorts, and forwards 
to the buyer. (Shopping agents such as 
Andersen ConsuWng's BargainFinder 
are a special case of this service.) 

• Referrals and directory services han- 
dle buyer requests for referrals. These 
services match requests against pro- 
files of registered sellers using buyer- 

• Aggregation allows buyers to submit 
requests for goods and services, which 
the service pools with similar requests 
to obtain quantity discounts. 

The marketware framework supports 
these applications by providing a common 
set of structures and functions. 

• Standard profiles for buyers, sellers, 
and intermediaries. Profiles provide the 
information needed for a party to par- 
ticipate in market transactions. This 
information could include size and 
type of business, location and street 
address, terms, conditions, contracts 
supported, certificate information, cre- 
dentials, credit rating, and references. 

• Standard taxonomies of goods and ser- 



vices would allow parties to target par- 
ticular transactions and filter out oth- 
ers. Taxonomies would use standard 
commercial classifications such as SIC 
(standard industrial classification) 
codes as well as custom ones. For 
example, a three-level hierarchy would 
classify products by industry (for 
example, computer), subarea (periph- 
erals), and type (disk drives). 
CommerceNet Is working to develop 
an evolvable "Taxonomy of Every- 
thing" for products. 
Standard CBL commands to invoke 
market actions such as buy, sell, bid, 
post request for quote, and locate 
interested buyers or qualified vendors. 
Authentication and authorization 
functions that use buyer and seller 
profiles to control what information a 
party can see or modify. 
Accounting and reporting of transac- 
tions for buyers, sellers, and market 
administrators. 

A notification service allows buyers 
and sellers to register their interest in 
selected market events (a new-bid post- 
ing, for example) and receive a CBL 
notification message when they occur. 
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• Network services. Every Eco application will be 
a network-accessible service provided by agents. 

• Object Web. Eco agents respond to CBL mes- 
sages from other agents and to HTTP requests 
from browsers. 

• Industry compatibility. As currently planned, Eco 
will foster interoperability among four of the five 
major e-commerce frameworks. 

• De facto interoperation. Eco focuses on interop- 
eration rather than standards. It will achieve 
interoperation in many ways, including the use 
of de facto standards implemented in Java and 



HOP to achieve platform independence. Protocol 
negotiation, gateways, and mediators will pro- 
vide semantic interoperation. 

• Scaleable, interchangeable building blocks. 
Agents can direct CBL commands to a business, 
several businesses that have linked their catalogs 
or processes, a market (comprised of many com- 
panies) , or a third-party intermediary. 

• Transparent outsourcing. Eco will facilitate the 
outsourcing of business processes such as fulfill- 
ment, shipping, and payment p: 



Object orientation 

Every Eco System service is a network-accessible 
object. As shown in Figure 3, objects respond to agents 
using CBL commands delivered over HOP and to 
browsers using HTTP, HTML, and Java. This duality 
maintains compatibility with current Web sites and 
affords a graceful migration path. It's also compatible 
with emerging industry trends and anticipates the pos- 
sibility that the next generation of HTTP and HOP 
may someday merge. If the industry does not widely 
accept CORBA, agents will still be able to access the 
Web by using embedded semantic markup. Such 
embedded markup will let agents understand and 
respond to the information depicted graphically in a 
Web page. Microsoft and Netscape recently endorsed 
XML (Extended Markup Language), a simplified ver- 
sion of SGML used for embedding tags into HTML. 

As shown in Figure 4, Eco imposes a layer of mid- 
dleware on top of leading Internet commerce plat- 
forms such as Netscape ONE and Oracle NCA. It uses 
the CORBA HOP architecture supported by these 
platforms and extends it to accommodate CBL agents. 

Object bus. In CORBA, all objects connect to a com- 
mon object bus, as shown in Figure 5. Thus, although 
we often depict Eco services hierarchically as in Figure 
1, their actual implementation is flat; any Eco object 
can request a service from any other. This is conve- 
nient because situations do frequently arise where 
objects lower in the hierarchy require services from 
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Figure 5. ECo object request broker acts as a bus between object-encapsulated services. 
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those above. For example, premium network services 
such as quallty-of-servlce management or IP multi- 
cast may involve payments. Or a fulfillment service 
may need transportation I-market services. 

IDL. CORBA and HOP insulate application devel- 
opers from most implementation and runtime details. 
CORBA provides IDL, a neutral definition language 
not tied to any specific programming language. 
Compiling the IDL generates object-oriented code 
implementing APIs. This allows any vendor to pro- 
vide application object(s) that actually implement the 
specification. Vendors can write such objects in any 
language, and the objects can reside on any Internet- 
connected host. This architecture accommodates 
legacy applications by encapsulating them in an object 
wrapper and creating a corresponding IDL file as an 
interface. CORBA standardizes a CORBA-IDL-to- 
C++ mapping. JavaSoft and the OMG (Object 
Management Group) have released Java IDL alpha 
2.2 for mapping IDL to Java. 

Java. Object orientation allows developers to 
more quickly write and/or reuse applications to sup- 
port changing business environments. Maintaining 
Eco's object orientation requires the use of an object- 
oriented language; CommerceNet has selected Java 
for this task. 

Java is an interpreted language developed specifi- 
cally with heterogeneous distributed networks and 
applications in mind. Vendor-neutral bytecode can be 
securely downloaded from the network as an applet 
that runs on a virtual machine residing on the user's 
system, most likely a Java-enabled browser. The Java 



runtime has built-in security features such as a hyte- 
code verifier that enforces the Java security model (for 
example, disallowing pointers) and prevents malicious 
code from escaping the Java virtual machine (or 
"sandbox") and accessing the underlying operating 
system. Finally, Java Beans provides an architecture 
and platform-neutral API for creating and using 
dynamic Java components. Developers will be able to 
use a variety of development tools to assemble custom 
applications. These applications can draw on a rich 
variety of support services (such as event handling and 
persistence) that make Java Beans fully portable. 

Protocol negotiation, mediators, and gateways 

Application vendors are usually much more willing 
to agree on a metaprotocol than a standard. That's 
because a standard would require most to abandon 
rival technologies in which they have a substantial 
investment. Since today's computers can support mul- 
tiple protocols, negotiation is a practical way of real- 
izing de facto interoperation. 

Negotiation protocols, bridging gateways, and medi- 
ators (smart gateways) have a part in accomplishing 
interoperability. Often, an application may not care 
what protocol it uses: "Just tell me what protocol you 
prefer, and I'll accommodate it if I can. " This is the 
basic philosophy imderlying the JEPI payments frame- 
work (seethe "Payment Inter-operability" sidebar). In 
JEPI, sellers provide buyers with a list of payment types 
they accept (analogous to merchants displaying credit 
card logos in their store windows). Buyers then select 
the form of payment they wish to use, which implicitly 



Payment Interoperability 

In December 1995, the World Wide Web 
Consortium (W3C) and CommerceNet 
cosponsored the Joint Electronic Payment 
Initiative QEPI) to bring key industry play- 
ers together (CyberCash, IBM, Microsoft, 
Xerox, and British Telecom, among others) 
to ensure that multiple payment instru- 
ments, protocols, and transports will inter- 
operate over the Internet. 

JEPI is a metaprotocol built on top of two 
new Web protocols— PEP (Protocol Extens- 
ion Protocol) and UPP (Universal Payment 
Preamble) — that let clients and merchant 
servers negotiate among and select payment 
mechanisms. Clients and servers can ask 
each other what forms of payment they sup- 
port and negotiate a mutually acceptable 
payment mechanism. 

PEP is a protocol for extending HTTP so 
that it can dynamically deploy applications 
that require more facilities than those pro- 
vided by HTTP's request-response model. 
PEP associates new extensions to HTTP 
with a URL and uses a new Protocol; 
header field to can-y the extension identifier 



and otiier necessary information — includ- 
ing possibly an implementation of the 
extension — between clients and servers. 
Lilce Java's protocol handlers, PEP provides 
the capability to automatically and dynam- 
ically download software component inter- 
faces, enabling sophisticated applications 
such as distributed authoring tools to inter- 
operate over the Web. PEP has been sub- 
mitted to the IETF for inclusion in HTTP 

Don Eastlake built the Universal 
Payment Preamble on top of PEP UPP is 
intended to provide a minimal layer that 
lets customers use a multipayment wallet 
and easily move from payment to payment. 
It provides a uniform vocabulary and syn- 
tax for naming options common to many 
payment systems, enabling clients and 
sei-vers to exchange the necessary informa- 
tion and enter a specific payment system. 
This approach redefines each proprietary 
payment system as an URL-identified, PEP 
protocol extension implemented by a 
generic UPP protocol and module. 

UPP negotiations occur via exchange of 
PEP protocol headers before or during 
shopping. Negotiation requests available 



payment choices, presents multiple choices, 
demands or makes a selection, and accepts 
or rejects choices. The payment protocol 
guarantees security not UPR 

JEPI completed phase 1 in April 1997 
with a demonstration at the Sixth 
International World Wide Web Conference 
of a JEPI implementation comprising two 
payment instruments, CyberCash and 
GCTech's GlobelD. W3C met with its 
members at that meeting to consider phase 
2 strategies, which may include; valida- 
tion/revision of UPP/PEP (JEPI used the 
August 1996 version of PEP which was 
subsequently revised for consideration by 
IETF); incorporation of more payment 
sj'stems (SET and micropayments), smart 
card integration; wallet and cash register 
APIs; and extension of HTML for micro- 
payments. CommerceNet has committed 
to phase 2 development, according to 
CommerceNet 's Jim Galvin, project man- 
ager for JEPI. For more information, see 
Eui-Suk Chung and Daniel Dardailler's 
"White Paper; Joint Electronic Payment 
Initiative (JEPI)," http;/www. w3.org/ 
pub/WWW/Payments/white-paper.html. 
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AIMSNet 

B.w.S'iKW. 

AIMSNet, a product of the Agile 
Infrastructure for Manufacturing Systems 
(AIMS) program, is a worldng example of 
an I-market in tlie making. Using AIMSNet, 
an intercompany network (using the 
Internet) links companies like Lockheed 
Martin and its suppliers, allowing multi- 
company project teams to exchange techni- 
cal and business information, collaborate 
on design, post quotes and purchase orders, 
tender or accept bids, find potential suppli- 
ers and partners and track project mile- 
stones. More than 10 companies currently 
use AIMSNet, and dozens more arejoining 

One of AIMSNet's powerful features is 
support for coUaboi'ative design. Its 
Multimedia Environment for Collaborative 
Engineering (MECE) is an online, shared 
notebook system developed by Lockheed 
Martin. This allows project team members 
to assemble and share information, such as 
design rationale and program decisions, in 



the form of text, audio, video, and screen 
snapshots. It also accommodates 3D design 
and manufacturing information by using 
VRML. VRML provides a 3D model inde- 
pendent of any specific CAD program. 
Team members use these tools to review 
information, collect comments, and make 
recommendations and changes. Current 
AIMSNet users are large programs within 
aerospace companies that develop complex 
systems such as satellites, rocket engines, 
missiles, and so on. 

This effort, funded by the US Defense 
Advanced Research Projects Agency, has 
also developed templates to standardize 
ti'ansactions between companies. An impor- 
tant e-commerce concept, templates convey 
information between coinpanies in a stan- 
dard format easily accessed from anywhere 
tlirough a HTML browser. Users can 
import information from legacy systems as 
well as tlTiough industry standard protocols. 
These templates also ser\'e as simple front- 
end-to-reniote databases tliat are network 
accessible. 



Work is in progress to provide multitier 
supply chain coordination and facilities for 
evaluating and selecting suppliers. The 
coordination agent enables team members 
to track events critical to a project's suc- 
cess. The agent filters, sorts, prioritizes, and 
presents status information coming from 
various sources to project members based 
on their requirements. This helps project 
members manage the project from their 
own perspective. The supplier selection 
agent provides a mechanism for rapidly 
identifying key partners that can meet a 
project's multiple criteria. AIMSNet cur- 
rently offers users a preliminary version of 

AIMSNet, an industrial commerce infra- 
structure, is currently piloted as an aero- 
space I-market but can be easily customized 
to several other I-markets including auto- 
motive, electronics, and construction. 

Rani Stirain is AIMS Program Dtector for 
Lockheed Martin Missiles & Space. 
Contact him atsriram @aic, lockheed. com. 
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Figure 6. IDL provides a neutral definition language for connecting distributed applications 
(through CBL and Eco agents) in a platform-independent manner. 



selects the appropriate protocol (SET or Mondex, for 
example). 

An alternative to protocol negotiation Is simply to 
translate between proprietary protocols using a gate- 
way service. Gateways work well with functionally 
similar protocols that differ in syntactic details. Thus, 
gateways are often a good way for legacy database 
applications to communicate (for example, my SAP 
purchasing system can talk to your Oracle order-entry 



system) because the applications involved are rea- 
sonably well standardized at a functional level. 

Gateways can also complement protocol negotia- 
tion. Namely, one alternative can be for each party to 
adhere to their favorite protocol and employ gateway 
services. In effect, the parties aj 

Mediators are smart gateways, which ce 
a mutually acceptable protocol with each of several 
sites, retrieve information from each site, and integrate 
it. Mediators were originally developed for advanced 
information retrieval tasks, but are well-suited to e- 
commerce tasks such as integrating the catalogs and 
business systems of several cooperating firms. 

Common Business Language 

NSI messages, business objects, and product tax- 
onomies will constitute a CBL for Internet commerce. 
Eco extends HOP by adding two new levels of abstrac- 
tion: CBL messages and CBL agents. A CBL message 
is an object-oriented alternative to the ad hoc text 
strings currently used in electronic data interchange. 
Each framework inherits the service requests and busi- 
ness objects of those frameworks upon which it builds, 
specializing and extending the inherited entities to pro- 
vide new functions. 

CBL agents provide a baseUne s 
(Telescript-like) services that all e- 
tions can build on. They include basic authentication. 



Compute 



EDI Interoperability Testing 

EDIINT, the Internet Engineering Task 
Force (IETF) workgroup, has recommended 
standards for interoperable, secui'e electronic 
data Interchange over the Internet. Com- 
merceNet is sponsoring interoperability test- 
ing of these EDIINT recommendations 
among implementations from 10 vendors. 
These vendors include Actra Busijiess Systems 
(a Netscape/GEIS company), Atlas Products 
International, AT&T, CyberPath, DaNet, 
Digital Equipment Corp., EDS, HcU-binger, 
Premenos, and Sterling Commerce. 

The vendors are ciiecking the ability of 
tlieir products to pass EDI securely among 
themselves. In January, five vendors 
demonstrated the successful exchange of 
digitally signed data among their products. 
This demonstration involved passing elec- 
tronic documents over SMTP (Simple Mail 



Transport Protocol) using S/MIME (Secure 
Multipurpose Internet Mall Extension) 
encoding. Although tire products all imple- 
ment the S/MIME standard, factors such 
as certificate version differences and 
S/MIME support for multipart/signed doc- 
uments still caused short-term interoper- 
ability problems. 

Rik Drummond is chair of tlie lEFT 
working group, manager of the testing, and 
principal of the Drummond Group, an e- 
commerce consultancy. He anticipates tile 
results of the EDIINT recommendations 
and the assurance of the CoinmerceNet 
interoperability testing to result in several 
secure, interoperable, off-tlie-shelf Internet 
EDI products in the next few months. The 
first group of five vendors will complete the 
total testing — exchanges of certificates, 
encrypted and signed messages, and signed 



receipts — by mid-May. A signed receipt is 
the basic mechanism for nonrepudiaton of 
receipt. In addition, the IETF is reviewing 
two draft standards— "MIME-Based 
Secure EDI" and "EDIINT Functional 
Specifications" — that outiine tlie basis for 
secure, interoperable, Internet EDI. These 
standards set forth functional requirements 
for encryption, key management, content 
integrity, authentication, receipts, and track- 
ing and error handling. They also recom- 
mend existing standards that fulfill these 
requirements. Both documents are available 
at http://www.ietf.org/ids.by.wg/ediint.html. 
Drummond expects these drafts to be 
accepted as Requests for Comments within 
the next few months. For more information 
about either the CommerceNet interoper- 
ability testing or the standards, contact him 
at drummond@onramp.net. 



authorization, billing and accounting, micropayment, 
and directory services. We will base these agents on 
several Hghtweight agent architectures developed for 
use with Java, including IBM's Aglets and Mitsubishi's 
Concordia. 

Eco's agent platform, depicted in Figure 6, provides 
an agent transport protocol and associated manage- 
ment and support services (creating and destroying 
agents, subcontracting tasks, delegating permissions 
and resources, and administering offers to buy or sell 
services) . Using IDL, the CBL stub translates CBL 
messages into object requests to use IlOP-provided 
Interoperability services. 

PROJECT STATUS 

In addition to the four major platform vendors, other 
organizations are active CommerceNet participants — 
Actra, Bank of America, Vlsigenlc, the World Wide Web 
Consortium, and NIST, to name a few. CommerceNet 
recently agreed to cooperate with five Japanese organi- 
zations—NTT, the Japan Research Institute, Mitsubishi, 
NEC, and Oki — in developing functional prototypes of 
I-markets for a mall of maUs and auto parts procure- 
ment. Additional I-market pilot programs include those 
for real estate and aerospace. The latter is already a 
working Internet-based network for manufacturing 
procurement; see the "AIMSNet" sidebar. 

Another area in which CommerceNet is making a 
significant Impact is in establishing standards and test- 
ing for secure electronic data Interchange (see the 
" EDI Interoperability Testing " sidebar) . 

Although projects like AIMSNet allow pre-estab- 
lished trading partners to work together, we will use 



its residts and EDI to create open I-markets in which 
an entire industry can come together for trade. 

Internet commerce stands at a crlticaljuncture. After 
an exhilarating start-up, further development 
hinges on bridging the chasm between early 
adopters and a true mass market. We envision Eco 
System as the foundation of that bridge. 

Eco System is notjust about creating an architectural 
framework of frameworks. It is, more Importantly, 
about establishing an ongoing process and organization 
for achieving broad industry consensus on Interoper- 
ability and reuse issues critical to open e-commerce. 
These issues are changing daily; visit http://www. 
commerce.net/Eco for the latest information. ❖ 



Jay M. Tenenbaiim is founder and chair of Com- 
merceNet, an industry association for e-commerce. 

Tripatinder (Trip) S. Chowdhry, cofounder of tlie 
CommerceNet group, is the chief aivliitect of Eco Sys- 
tem. Chowdhiy received his MBA h orn Kellogg Grad- 
uate School of Management and an MS in computer 
science from the University of Southern California. 

Kevin Hughes is a consultant and CommerceNet Fel- 

Contact Tenenbaum at CommerceNet, 4005 Miranda 
Ave.. Suite 175, Palo Alto, CA 94304; jmt@ 
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Robert J. Glushko, Jay M. Tenenbaum, 
AND Bart Meltzer 

AN XML FRAMEWORK 

FORAgent-based 
E-commerce 

Emerging standards for commercial document exchange 
promise open business-to-buslness e-commerce. 

ommerceNet's eCo System initiative, launched in 

■ 1996, aims to transform the World-Wide Web into an 

w agent-based infrastructure for Internet commerce. 

Today's Web gives people unprecedented access to online 

information and services. But its information is delivered 

Jjjjl in format-oriented, handcrafted hypertext markup lan- 

■P guage (HTML), making it understandable only through 
r 

human eyes. Software agents and search engines have dif- 
ficulty using the information because it is not semantically encoded. Clever programmers work 
around some of HTML's inherent limitations by using proprietary tags or software that 
"scrapes" Web pages to extract content. Unfortunately, such ad hoc approaches do not scale. 
Proprietary tags require browser plug-ins, and scraping approaches require a customized script 
for each Web site. These approaches balkanize the Web, making it inaccessible to agents. 
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Tomorrow's Web will use the extensible markup 
language (XML) to encode information and services 
with meaningful structure and semantics that com- 
puters can readily understand. In Internet com- 
merce, companies will use XML documents for 
publishing everything from product catalogs and air- 
line schedules to stock reports and bank statements. 
They will also use XML forms to place orders, make 
reservations, and schedule shipments. Any agent 
with the proper authorization will be able to obtain 
computer-interpretable data sheets, price lists, and 
inventory reports through the Web or email, then 
request quotes, place orders, and track shipments. 

By making the 
Web accessible to agents 
and other automated 
processes, XML will fun- 
damentally transform the 
nature of e-commerce (see 
Maes et al. s "Agents That 
Buy and Sell" in this 
issue). XML will elimi- 
nate the need for custom 
interfaces with every cus- 
tomer and supplier, allow- 
ing buyers to compare 
products across many 
vendors and catalog for- 
mats, and sellers to pub- 
lish their catalog 
information once to reach 
many potential buyers. 
Online businesses will 
also be able to build on 
one another's published 
content and services to 
create innovative virtual 
companies, markets, and 
trading communities. 

Web merchants might initially dread that XML- 
encoded information makes it too easy for buyers to 
compare prices and competitors to co-opt their con- 
tent. But fear of lost business opportunity as e-com- 
merce grows and the recognition that XML provides 
many other advantages for sellers (such as the ability 
to differentiate products in ways other than price) 
are likely to convince them to adopt richer markup 
formats, (see Wong et al.'s "Java-based Mobile 
Agents" in this issue). In time, most merchant Web 
sites will provide agent-searchable catalogs that sup- 
ply product descriptions, as well as information 
about price and availability. 

For consumers, the most obvious result of perva- 
sive markup will be smart shopping agents that level 



the playing field in their dealings with sellers. Using 
Internet-wide shopping directories, these agents will 
be able to locate all merchants carrying a specific 
product or service, then query them in parallel to 
locate the best deals. Some merchants will provide 
sales agents that negotiate with shopping agents and 
generate customized offers in response to their solic- 
itations. The shopping agents can then sort the 
offers they receive according to criteria set by their 
owners — the cheapest flight, the most convenient 
departure time, the roomiest aircraft, or some 
weighted combination. Cybermediaries will offer 
innovative brokering and referral services that match 
buying and selling 
agents, as well as order- 
aggregation services that 
increase their purchas- 
ing clout. 

Agent-based shop- 
ping by consumers is 
just the tip of the e-com- 
merce iceberg. When- 
ever a product is bought, 
information propagates 
back down the supply 
chain, triggering a series 
of distribution, manu- 
facturing, and logistics 
events. Today much of 
this business-to-business 
information is exchanged 
through EDI messages. 
But traditional EDI is 
complex and expensive, 
because most messages 
travel over proprietary 
networks. Moreover, 
EDI's brittle syntax 
necessitates a custom integration solution between 
each pair of trading partners. 

For these reasons, EDI transactions will increas- 
ingly take place over the Internet using an 
XML/EDI message format. Such messages will be 
more economical than traditional EDI messages, 
while being easier to validate and translate into the 
formats needed by applications at each end of the 
exchange [4] . This development will encourage busi- 
nesses, including many that find traditional EDI too 
costly, to implement Web agents that respond to 
XML messages. This agent-based approach to enter- 
prise integration is simpler and more open than tra- 
ditional EDI, because it avoids the "pairwise 
tyranny" through which big companies impose pro- 
prietary message formats on small companies. More- 
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Figure I . A supply Web linking PC manufacturers, 
distributors, and resellers 




Supplier 

Figure 2. XML-based document exchange in the eCo Syster 



over, publishing XML-encoded documents, such as 
data sheets and price Usts, on the Web makes the 
information available instantly to all potential trad- 
ing partners. Instant availability transforms rigid 
supply chains into "supply Webs," in which partici- 
pants transact business spontaneously (see Figure 1). 

The eCo System began as an architectural vision 
for open Internet commerce [5], proposed and evan- 
gelized by the 500-member worldwide Com- 
merceNet Consortium in 1996. Conceived 
originally as a CORBA-based interoperability frame- 
work, the eCo System architecture was recast in 
1997 on an XML foundation, due to XML's sim- 
plicity and widespread adoption by key vendors, 
including IBM, Microsoft, Netscape, and Sun. 

Todays eCo System enables companies to com- 
municate over the Internet using self-defining XML 
business documents that agents, as well as people, 
can easily understand. Business Interface Definitions 



(BIDs), posted on the Web, tell 
■■■■ potential trading partners what 
"""" online services a company offers and 
what documents to use when invok- 
ing those services. For example, a 
BID might allow a customer to order 
goods by submitting a purchase order 
or a supplier to check availability by 
GS/% downloading an inventory status 

report (see Figure 2). 

A key element of the eCo System 
framework is the Common Business 
Library (CBL), an extensible, public collection of 
generic BIDs and document templates that compa- 
nies can customize and assemble to go online 
quickly.^ CBL includes XML message templates for 
the basic business forms used in ANSI X12 EDI 
transactions, as well as those used in such emerging 
Internet specifications as Open Trading Protocol 
(OTP) and Open Buying on the Internet (OBI). 
These specifications are mapped to each other using 
a dictionary of common business terms and data ele- 
ments. A company can thus define its business inter- 
face in terms of any Internet standard mapped to 
CBL and communicate instantly with every other 
company that has done the same, even when the 
companies subscribe to different standards. 

The eCo System framework overcomes two long- 
standing barriers to e-commerce. CBL facilitates 
spontaneous commerce between trading partners 
without custom integration or prior agreement on 
specific industrywide standards. And by being inter- 
pretable by both people and agents, XML docu- 
ments provide an incremental path to business 
automation, whereby browser-based tasks are gradu- 
ally transferred to computer agents. These advances 
eliminate much of the time, costs, and risks of tradi- 
tional system integration. Moreover, the eCo System 
transforms closed trading partner networks into 
open markets and extends such enterprise applica- 
tions as inventory management and production 
scheduling across entire supply chains. 

XML is a simplified metalanguage, derived from 
SGML, emerging as the standard for self-describing 
data exchange in Internet applications. XML was 
developed by the World-Wide Web Consortium in 
1997 and is being implemented rapidly by such 
major platform vendors as IBM, Microsoft, 
Netscape, and Sun Microsystems. XML's power 
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derives from its extensibility and ubiquity. Anyone 
can invent nevi^ tags for particular subject areas, 
defining what they mean in document type defini- 
tions (DTDs). Content-oriented tagging enables a 
computer to understand the meaning of data, 
including, say, whether a number represents a price, 
a date, or a quantity. 

This tagging significantly increases the function- 
ality of Web e-commerce applications, because they 
can now do much more than simply display product 
data. For example, items in an XML-encoded cata- 
log can be sorted by price, availability, and size. 

One of eCo System's longstanding goals has been 
to enable businesses to build on one another's ser- 
vices to create virtual enterprises. Such plug-and- 
play commerce involves modeling enterprises as 
collections of services, some internal to a particular 
business, others provided by trading partners. Busi- 
ness services in eCo were originally defined as 
CORBA application programming interfaces (APIs). 
While the CORBA approach appears workable 
within organizations that control APIs, our experi- 
ence in several prototypes suggests it is not practical 
for interenterprise integration. Fortunately, XML 
offers a promising alternative — agents interacting 
with business services through business documents. 

Business documents represent a more intuitive 



and flexible way to access business services than pro- 
gramming APIs. It is much easier to interconnect 
companies in terms of the documents they exchange, 
on which they already largely agree, than in terms of 
their business system interfaces, which invariably 
differ. The coupling is looser, but loose coupling is 
better than no coupling at all. 

XML's human readability is another significant 
advantage over CORBA. Just as HTML is a lan- 
guage for the eyes, CORBA is a language for CPUs, 
meant to convey information among programs, with 
no concession to human readability. XML docu- 
ments are as readily interpretable by humans as they 
are by computers, especially with the aid of a style 
sheet [2]. 

Other proposals for agent languages suggest that 
first-order logic or other formal languages enable 
more precise specification of messages than XML [1, 
3] . We prefer XML for two reasons — one language- 
theoretic, one practical. Expressing semantics in syn- 
tax rather than in first-order logic leads to a simpler 
evaluation function while needing no agreement on 
the associated ontologies. The practical argument, 
which is much more important for commercial suc- 
cess, is XML's ubiquity. The Web has made everyone 
appreciate the power of markup languages, practi- 
cally assuring the widespread adoption of XML, as 
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The power of XML in enabling interoperability and 
simplifying the sharing and reuse of information 
between business domains is encouraging compa- 
nies to work together to develop XML-based specifi- 
cations for the business information they exchange 
most often. Sample specifications include; 

• Open Trading Protocol. A consortium of banking, 
payment, and technology companies is specifying 
information requirements for payment, receipts, 
delivery, and customer support (www.otp.org). The 
goal of OTP is efficient exchange of information 
when the merchant, the payment handler, the deliv- 
erer of goods or services, and the provider of cus- 
tomer support are different entities with their own 

• XML/EDI. A group chartered jointly by Com- 
merceNet, ANSI X12, and the Graphics Communica- 
tion Association is defining how traditional X12 EDI 
business data elements should be represented using 
XML (www.xmledi.com). 

• RosettaNet. This PC industry initiative is defin- 
ing how to exchange PC product catalogs and trans- 



actions among manufacturers, distributors, and 
resellers (www.rosettanet.org). 

• Open Buying on the Internet. The OBI initiative, 
launched by American Express and major buying and 
selling organizations, including Ford Motor and Office 
Depot, is automating large-scale corporate procure- 
ment of office and maintenance supplies 
(www.openbuy.org) 

• Information and Content Exchange. CNET, News 
Corp., Vignette, and other information content 
providers are developing ways through ICE to create 
and manage networked relationships, such as syndi- 
cated publishing networks, Web superstores, and 
online reseller channels 

(www.w3.org/TR/1998/NOTE-ice-19981026). 

• Open Financial Exchange. Originally proposed by 
CheckFree, Intuit, and Microsoft for the electronic 
exchange of financial statements among consumers, 
small businesses, and financial institutions, the OFX 
effort supports banking, bill payment, investment, 
and financial planning activities (www.ofx.net). 
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Share the Ontology in XML-based Trading Architectures 



first faring- semantic ordei' to the wodd of XML. 

Howard Smith and Kevin Poulter 

Recent e-commerce application activity involving the 
extensible markup language (XML) has led to a prolifera- 
tion of XML-based standards and markup language pro- 
posals. Among them are several designed to support 
site-to-site Web automation that lean naturally toward 
the agent paradigm of distributed computation. 

Although XML represents a major step forw/ard in e- 
commerce technology, business-to-business trading 
partners should also recognize XML's limitations. XML is 
not a cure-all for system interoperability, but a widely 
accepted foundation layer on which to build. Moreover, 
there are differing views on how to extend or complement 
XMLto support agent-based e-commerce (see Glushko et 
al.'s "An XML Framework for Agent-based E-commerce" in 
this issue). This challenge is further complicated by 
debate over some fundamental questions: How should 
XML be extended to support the representation of busi- 
ness information? Should XML be enriched with tags 
reflecting higher-level concepts, especially business 
domains, such as standard business processes? How 
should foundation ontologies (from which higher-level 
content is composed) be defined? How can the numerous 
heterogeneous e-commerce frameworks (such as ICE, 
OBI, OTP, andXML/EDl) be unified to enable the expected 
low-friction market of the future? And will the future 
electronic marketplace be dominated by a series of com- 
merce islands with trading groups isolated by the propri- 
etary protocols and domain models with which their 
commerce agents interact? 

Answers involve not only solving the related technology 
and intellectual challenges, but how to bring together the 
various communities of industrial standards developers. 
Each holds the essential elements of the overall solution. 
These communities, including EDI, Internet, knowledge 
engineering, and SGML, bring to the table subtly differing 
angles on the problem, including representation 
approaches associated with rich documents, 
publish/subscribe protocols, transactions, content syndi- 
cation, and business semantics. To survive in this market, 
e-commerce component providers will have to support a 
number of different content formats and transaction 
frameworks, translating among them to achieve signifi- 
cant penetration. It appears that the main barrier to e- 



commerce lies in the need for applications to share infor- 
mation, not in the Internet's reliability and security. 

Due to the wide range of enterprise and e-commerce 
systems being deployed by businesses and the way these 
systems are variously configured, the problem is particu- 
larly acute among large electronic trading groups. E-com- 
merce will increasingly focus on trans-enterprise 
communication, while the number of trading partners and 
sophistication of e-commerce applications also increase. 
The need to unite business models, processes, and repre- 
sentation formats is greater than ever, while expectations 
run ever higher. Although many companies have already 
begun to organize, standardize, and stabilize their digital 
services in order to create and maintain sustainable net- 
work relationships with their trading partners, they are 
doing so only in conjunction with their immediate trading 
partners. This relatively narrow focus can limit the return 
on investment possible from each of these initiatives. 

A global environment. There is now a need for e-com- 
merce participants to create a global environment provid- 
ing significant interoperability between the systems used by 
all engaged. Such an environment can be achieved through 
improved semantics within Internet transactions and in 
networked service definitions. It will facilitate consistent 
behavior among participants in large trading networks or 
within complex virtual organizations. Many of the founda- 
tion concepts needed to achieve this consistent behavior 
have already been established through work on distributed 
problem solving, intelligent agents, and knowledge sharing, 
yet to date these technologies have had little effect on 
Internet-based commerce. 

Agent-based systems to support the next generation of 
Internet commerce must adopt common ontologies if they 
are to interact without misunderstanding. For example, 
content can be defined to enable application interoperation 
as well as information synthesis. An e-commerce standard 
being developed by major PC vendors, resellers, and distrib- 
utors has shown by practical example in the PC distribution 
chain that quite sophisticated representation Issues can 
complicate even straightforward commerce scenarios. For 
example, the required catalog model includes the need to 
represent the topology of the parts comprising a PC product. 

But to bring semantic order to the world of XML, we have 
to be clear about what we mean by "ontology," The term is 
often used to refer to a vocabulary, yet even the terms 
within a simple vocabulary can be prone to misinterpreta- 
tion, particularly in combination, unless they have been 
chosen carefully. Consider some of the problems already 
apparent in the plethora of e-commerce standards that 



have emerged during the past few years. As new online 
trading environments are developed, the potential proto- 
col mismatches between participants' commerce plat- 
forms can become major inhibitors to achieving 
industrywide e-commerce solutions and delivering sup- 
ply-chain and market-efficiency benefits. Realizing Web 
automation in such complex environments reopens many 
of the problems and issues the knowledge-sharing and 
intelligent-agent communities have been wrestling with in 
such initiatives as the shared design environment, or 
SHADE, and the advanced technology operations system, 
or ATOS, using ontologies to enable agents working on dif- 
ferent problems to interoperate over networks. 

XML as a representation is just too forgiving at the 
document type definition (DTD) stage at the expense of 
the information processing stage. However, steps are 
being taken in the right directionj an example is the defi- 
nition of schema languages to enable consistent schema 
semantics in the definition of objects in XML (such as by 
the World-Wide Web Consortium reflecting proposals from 
a number of organizations). 

Consistent schema semantics will certainly enable effi- 
cient e-commerce using predefined DTDs between fixed 
networks of trading partners. But to enable the full bene- 
fits of agent-based e-commerce— where agents act in an 
autonomous or semiautonomous way, comparing and 
contrasting products or suppliers and negotiating with 
other agents — participating agents have to communicate 
in terms of a detailed ontology of the business domain. 

The challenge for technology vendors, e-commerce 
participants, and standards bodies is to capitalize on the 
experience available in the knowledge representation and 
distributed agent communities. 

Veo Systems is pursuing a pragmatic approach to solv- 
ing some of these issues through the Common Business 
Libraty, an extensible, public collection of business inter- 
face definitions and document templates. This library is 
being rationalized and further developed by the Com- 
merceNet eCo Framework Working Group established last 
year and should provide a foundation for addressing 
many of the unanswered questions in agent-based e- 
commerce. Ontologies will play a key role. B 

HowAED Smith (howafd.smith@ontolog)r.org) is the direaor of 
Ontology. Org and a principal consultant (Internet) in Computer Sciences 
Corp. in Farnborough, Hampshire, U.K. 

KevJN PouLTER (kevin.poultet@ontology.org) is chief technology oificer of 
Ontology.Oig and a principal consultant in Computer Sciences Corp., U.K 
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HTML's heir apparent. XML may be theoretically 
less expressive than other formal languages, but we 
prefer a language that can be understood and pro- 
duced by computer novices to a theoretically bet- 
ter one spoken only by computer scientists. 

The significance of XML for integration 
extends beyond the Web to email, database 
records, and programming APIs. An XML parser 
imposes the same API on any XML data source, 
eliminating much of the need for custom pro- 
grams to extract and integrate information from 
each source. So, integrating enterprise informa- 
tion from accounting, purchasing, manufacturing, 
shipping, and other functions can be accom- 
plished by first converting each source to XML 
and then processing the parsed data stream. Put 
another way, each application need know only two 
source formats — its own and XML^ — rather than 
having to produce the native format of every other 
application. 

XML by itself doesn't enable plug-and-play 
commerce. In addition to the language itself, a 
complete business integration solution also 
requires: standardized tags, or metadata, for each 
commerce community; a means for mapping 
between different metadata descriptions; and a 
server for processing XML documents and invok- 
ing appropriate applications and services. The eCo 
System framework starts with XML and adds these 
additional architectural and technology elements. 

Specialized Marl<up Languages 

XML makes it easy to create specialized markup 
languages that identify and describe buyers and 
sellers, the goods and services they want to buy or 
sell, and the various other document types 
involved in commerce. However, a vendor has 
obvious incentives for describing its offerings in 
ways that highlight its competitive advantages and 
that obscure comparison on features where it lacks 
an advantage. But if every business invented its 
own XML definitions for product catalogs, 
requests for quotes, price lists, purchase orders, 
invoices, transportation schedules, shipping 
notices, and delivery and payment receipts, the 
Web would be scarcely more usable as a platform 
for agents and other automated processes than it is 
today (see Smith's and Poulter's "The Role of 
Shared Ontology in XML-based Trading Archi- 
tectures" in this issue). 

Fortunately, many companies already recognize 
the need for information-exchange standards, 
uniting in several initiatives focusing on XML 
standards for particular industries or business 



COMMUNICATIONS OF THE ACM March 1 999/Vol. 42, No. 3 I I I 



Business Descriptio 
I Vendor 



[1 



]] I Catalog 



3 



Purchase Order 



I Products [ i I Invoice 



Measurements 



I Currency ~| i: | Country 



I Language 



Figu, 



>. The Common Business Library 



processes (see the sidebar "Domain-specific E-com- 
merce Languages"). Unfortunately, these initiatives 
operate independently, doing little to facilitate inter- 
action across industry and functional boundaries. 
The solution is to spur development of XML docu- 
ment models based on reusable semantic compo- 
nents common to many business domains. Such 
documents can be understood by any business 
through their common elements (such as address, 
date, and part number), while also providing a com- 
mon mechanism for linking to the unique elements 
vendors need to differentiate themselves. 

The CBL is designed to encourage development 



and use of generic XML docu- 

ment models. The library con- 

ill ^ I p sists of information models for 
various concepts, including: 

• Business descriptions, such as 
companies, services, and 
products; 

• Business forms, such as cata- 
^ i 6 logs, purchase orders, and 

invoices; and 

:iassification * Standard measurements, such 

1 as date and time, location, 

and classification codes. 

ICS I 

: [ i These models are represented 

as an extensible, public set of 
XML building blocks that com- 
panies can customize and assemble to develop XML 
applications quickly. Atomic CBL elements imple- 
ment industry messaging standards and conven- 
tions, such as standard International Organization 
for Standardization (ISO) codes for countries, cur- 
rencies, addresses, and time. Low-level CBL seman- 
tics are also derived through analysis of proposed 
metadata frameworks for Internet resources, such as 
the Dublin Core metadata element set developed by 
the Online Computer Library Center. 

The next level of CBL elements use these build- 
ing blocks to implement the basic business forms 
used in XI 2 EDI transactions, as well as those in 
OTP, OBI, and other emerging Internet standards. 
A working group organized by CommerceNet and 











ice. name >Order Service</serv 






ice. location>www.veosystems . 


com/ order</service . location> 




ice.op> 






i ce. op. name > Submit Order</se 


rvice.op.name> 




ice . op . inputdoc >www . commerce 


.net/po . dtd</service . op . inputdoo 




ice . op . output>www . veosystems 


. com/ invoice . dtd</service . op . outputdoo 


</ser 


vice.op> 
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ice.op.name>Track Order</ser 


vice.op.name> 




ice . op . inputdoowww . commerce 


. net/request . track . dtd<service . op . inputdoo 




ice . op . outputdoowww . veosyst 


ems . com/ response . track . dtd<service . op . outputdoo 


</ser 


vice.op> 




</ser 







Figure 4. Fragment of an XML service definition for an eCo-compliant business applic: 
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other organizations recently 
began using CBL to create a 
base set of common terms, or 
mappings, between existing 
terms in commerce specifica- 
tions, including OBI and 
OTP. The final result sched- 
uled for release in mid-1999 
will include a recommended 
base set of XML data elements, 
attributes, and definitions for use in e-commerce 
standards initiatives; they will be made freely avail- 
able in public registries run by CommerceNet and 
other organizations. The Internet community, build- 
ing on this foundation, will be encouraged to con- 
tribute additional elements and document models. 

Figure 3 shows how Federal Express might use 
CBL to create an XML version of its airbill by cus- 
tomizing a generic purchase order DTD with specific 
information about shipping weight. The generic pur- 
chase order, in turn, is assembled from more primi- 
tive CBL modules for address, date and time, 
currency, and vendor and product description. This 
example shows how reusing CBL components can 
significantly speed development of XML e-com- 
merce applications and facilitate their interoperation. 

When creating CBL, we found it helpful to 
extend XML with a schema language. The exten- 
sions add strong typing to XML elements so content 
can be readily validated. For example, an element 
called CPU_clock_speed. can be defined as an 
integer with a set of valid values: {100, 133, 166, 
200, 233, 266 Mhz}. The schema language also adds 
class-subclass hierarchies, so information is readily 
instantiated from class definitions. A laptop, for 
instance, can be described as a computer with addi- 
tional tags for such features as display type and bat- 
tery life. These and other extensions facilitate data 
entry, as well as automated translations between 
XML and traditional object-oriented and relational 
data models. 

Trading partners not only have to agree on the 
meaning of message tags but understand how to use 
them for conducting business. In the eCo System, 
BIDs tell potential trading partners what online 
business services a company offers and which docu- 
ments to use when invoking those services. In effect, 
services are defined by the documents they accept 
and produce. BIDs present a clean and stable inter- 
face to business partners, insulating them from a 
company's internal changes in technology, organiza- 
tion, and processes. 

Figure 4 shows a fragment of a BID, defining an 
XML service for an eCo-compliant business. The ser- 



Agent'based shopping by 

consumers online is just the 
tip of the e-commerce iceberg. 



vice definition consists of two transactions — one for 
taking orders, one for tracking them. Each definition 
expresses a contract, or promise, to carry out a service 
if a valid request is submitted to the specified Web 
address. The order service requires an input docu- 
ment conforming to a standard po . dtd DTD in 
an industry registry operated by CommerceNet. If 
the service is able to fulfill the order, it returns a doc- 
ument conforming to a customized invoice . dtd 
whose definition is local. In effect, the company is 
promising to do business with anyone submitting a 
purchase order conforming to the XML specification 
it declares. No prior arrangement is needed. 

A DTD is the formal specification, or grammar, 
for documents of a given type, describing the ele- 
ments, their attributes, and the order in which they 
have to appear. For example, purchase orders typi- 
cally include the names and addresses of the buyer 
and seller, a set of product descriptions, and associ- 
ated terms and conditions, such as price and delivery 
dates. In the EDI world, the X12 850 specification is 
a commonly used model for purchase orders. 

From Business Services to 
Virtual Enterprises 

eCo servers provide the glue that links a set of inter- 
nal and external business services to create a virtual 
enterprise or trading community. The server parses 
incoming documents and invokes the appropriate 
services (as specified by the applicable BID) by, say, 
handing off a request for product data to a catalog 
server or forwarding a purchase order to an enter- 
prise resource planning system. The eCo server also 
handles translation tasks, mapping the information 
from one company's XML documents onto docu- 
ment formats used by its trading partners and into 
data formats required by its own legacy systems. 

Following the service definition in Figure 4, when 
a company submits a purchase order, the XML 
parser in the eCo server uses the purchase order 
DTD po . dtd to transform the purchase order 
instance into a stream of information events. These 
events are then routed to any applications pro- 
grammed to handle events of that type; in some 



cases, the information is forwarded over the Internet 
to an entirely different business. In the purchase 
order example, information coming from the parser 
may be acted on by various applications: 

• An order entry system processing the purchase 
order as a complete message; 

• An enterprise resource planning system checking 
inventory for the products described in the pur- 
chase order; 

• A customer database verifying or updating a cus- 
tomer's address; 

• A shipping company system using the address 
information to schedule a delivery; and 

• A bank system using credit card information to 
authorize a transaction. 

However, what is most important in such process- 
ing is what is left out. Trading partners need agree only 
on the structure, content, and sequencing of the busi- 
ness documents they exchange, not on API details. 
How a document is processed and what actions result 
are strictly up to the business providing the service. 
This focus on commerce elevates enterprise integra- 
tion from the system level to the business level. 

A True Marketplace 

eCo Systems top-level goal is to transform the Web 
into a true marketplace by enabling spontaneous, 
peer-to-peer exchange of electronic business docu- 
ments among all companies. This document-based 
approach replaces complex, expensive, and propri- 
etary business integration solutions with one that is 
simple, affordable, and open. 

The eCo architecture recognizes that a single 
dominant e-commerce standard is unlikely, even 
within a particular business community (and cer- 
tainly not across communities). Rather, there will be 
many standards. CBL, in particular, is not a single 
standard but a collection of common business ele- 
ments underlying all EDI and Internet commerce 
protocols. Its reusable components speed implemen- 
tation of standards and facilitate interoperation by 
providing a common semantic framework. This 
approach to standards implementation and interop- 
eration is fundamentally different from that taken 
historically by standards organizations and software 
vendors. It occupies an openness high ground 
embracing all the new competing standards being 
developed to take advantage of XML. 

The eCo system framework and CBL are being 
evaluated in several of the standards initiatives listed 
in the sidebar on domain-specific commerce lan- 
guages, as well as two major market trials sanctioned 



by CommerceNet: 

• The U.S. General Services Agency (GSA). The 
largest buying organization in the U.S., GSA is 
creating catalog interoperability across numerous 
government agencies. Until now, the catalogs 
belonging to participating agencies were imple- 
mented as relational databases, as static files, or as 
catalog applications. An eCo server transforms 
each of these information sources into a standard 
catalog service that responds to CBL queries by 
outputting an XML data stream conforming to a 
common catalog schema. The integrated source 
catalogs can then be searched through specialized 
user interfaces developed by various participating 
technology vendors. 

• RosettaNet. The RosettaNet consortium of PC 
manufacturers, resellers, and distributors is devel- 
oping integration standards for the PC distribu- 
tion channel; participants include Compaq 
Computer, CompUSA, Dell Computer, Hewlett- 
Packard, IBM, Ingram Micro, Merisel, Microsoft, 
and Tech Data. 

The XML document models used in these initia- 
tives are being rationalized to identify common 
semantic elements. These elements will be added to 
various public CBL repositories and made freely 
available (for more detail, visit viww.commerce.net 
andwww.veosystems.com). B 
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Exhibit C. "index.html" from cbl/072 directory (file date stamped in 
1997) 



Common Business Language (CBL) 



Version 0.7.2 

Terry Allen 

5 December 1997 

Copyright 1997 CNgroup, Inc. 

Purpose 

The purpose of the Compound Business Architecture(TM)(SM), or CBA(TM)(SM), is to 
specify common semantics, syntax, and message paclcaging for information held by and 
exchanged between electronic commerce components. Its focus is on the fimctions and 
information that are common to all business domains. For the time being, the Compound 
Business Architecture is known as the Common Business Language (CBL). 

Major Changes from the Previous Version (0.7.1) 

• reworked the MIME specification again, reinstating command . dtd per popular 
demand. 

Common Semantics 

The semantics of CBL are to be drawn from international standards where appropriate. 

Where appropriate, semantics are drawn from the UN/EDIFACT Basic Semantic Unit 
data dictionary and certain ISO and IETF standards. Modules constructed to date are: 

• datetime.mod. for Date and Time 

• measures.mod. for Weights and Measures 

• currency .mod, for Currencies 

• countrys.mod and addresso.mod, for Geographical Information 

• commatts.mod. for XML attributes common to all modules 

• ttlattri.mod, for XML attributes having to do with valid start and end dates and 
times for elements 

• pointers.mod, mostly for pointers to typed information 

• servprim.mod, for elements used in service description DTDs 

• servmeta.dtd, for metainformation that servers keep about documents 

• meta.mod, for metainformation elements 

• price-mod, for Price Information 

• shipment.mod, for Shipping Information 



{00058297.DOC } 



e shipnote.dtd, for Shipping Notice 

e paymento.mod, for Payment Information 

• paynoteo.dtd , for Payment Notice 

• proddesc.mod, for a Simple Product Description 

• markdesc.dtd, for Marlcet Description 

• markpart.dtd, for Marlcet Participant Information 

• catentry.dtd. for a Simple Catalogue Entry 

• acatalog.dtd, for a Simple Full Catalogue 

• shopcart.dtd, for a Shopping Cart 

• transact.mod. to provide a mode-independent basis for 

• order.dtd. for a Purchase Order, and 

• invoiceo.dtd, for an Invoice 

• taxonomy.mod, for Product Taxonomy, which may occur in a catalogue entry 

In addition to these semantics of trade, we need semantics for the component-based 
services of our system, such as: 

• servdesc.dtd, for a Service Description 

• Directory (Registry) Profile, perhaps also Server Profile 

• servmeta.dtd, for a Server Metadata about Documents 

• rfq.dtd, for Request For Quote 

• Request For Proposal 

. ots.dtd, for Offer To Sell 

• inventoy.dtd. for Inventory Info 

• Authorization Information 

• Trading Partner Agreement 

To support message packaging and information discovery and exchange we add: 

• manifest.dtd, for a Manifest for MIME Message Contents 

• guide.dtd. for a Guide to Transaction Negotiation document that outlines the state 
of negotiation and the response expected from the other party 

• semantic.dtd, for DTD Semantics 

• cblcat.dtd. for URL-URN bookkeeping 

• command. dtd. for commands to CBL servers 

• modify.dtd. for describing modifications made to one documents in its revision 

• infodesc.dtd, for a Request for Information 

• response.dtd. Response to Request for Information 

Finally, within each industry, those semantics specific to its domain must be defined. 
This work generally falls outside of the semantics of CBL, although it can build on CBL. 
The following modules have been constructed but not yet classified. 

• schedule.dtd, for a Schedule for Events 

Syntax 
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CBL semantics are to be encoded in XML DTDs (Document Type Definitions), suitably 
modularized so that the semantic primitives found in CBL are available to all the XML 
DTDs used in the system. 

It may be convenient to make it an application convention of CBL that all instances must 
have as their root element the topmost element in the DTD to which they conform. This 
application could not be enforced by XML parsing, and would have to be enforced 
separately. No decision has been made on this point yet (a few DTDs have more than one 
top-level element, although it is intended to create more DTDs to eliminate that 
circumstance). 

For the semantics of specific industries Commerce Type Definitions (CTDs) are needed; 
these are XML DTDs for specific industries, but fall outside of CBL. 

CBL linking will employ, and if need be augment, the facilities of the XML Linking 
specification (XLL). As of the date of this document's writing, this specification was still 
unstable, and the details of the linking attributes in the CBL DTDs should be considered 
as a sketch. 

Message Packaging 

In addition to specifying semantics and syntax, CBL specifies a method of constructing 
messages out of muhiple parts, and how these parts are packaged for secure delivery 
using MIME. At present we are developing a "Compounddoc" Type Parameter Media 
Subtype and "CBL 1.0" Schema Parameter Value for MIME Multipart/Related for this 
purpose. This format involves the use of an instance conforming to the manifest.dtd . A 
manifest points to the parts of the MIME message by their Content-IDs, and calls out the 
Document Entity, which for CBL must be an instance of manifest . dtd. The MIME- 
plus-manifest layer gives us a generic compound document wrapping mechanism for 
XML and SGML (specified separately and short-circuited here), with a defined constraint 
on content for our own purposes. 

The manifest . dtd makes provision for the use of a catalogue that is not (yet) employed 
in CBL (and that may well not be the SGML Open catalogue). I envision that the 
complete list of all the pieces of the compound document will appear in the catalogue, 

The Guide document is entirely specific to CBL. (See the Guide to the Guide DTD) . It 
describes the compound document or compound document set formed by a transaction 
negotiation from the standpoint of CBL (and a human, thus this is a suitable view to use 
in an human interface such as the proposed VBBE). It looks as though a CBL MIME 
message would seldom end with a Guide document, and in my MIME examples I have 
included additional documents referred to by the Guide document. However, the Guide's 
references to other documents do not assume that they have been shipped along with the 
Guide. 
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For previous versions of CBL, I constructed documentation tliat has not been updated, 
although it may still be useful. For a scenario for registering information with a server see 
CBL Usage Scenario: Register Information . For a transaction, see CBL Usage Scenario: 
Simple Retail . 

XML Design Strategy and Test Files 

The . dtd modules invoke .mod modules and add element and attribute declarations to 
form schemas for XML documents useful in e-commerce. To combine them to form 
higher- lever schemas, we use DTDs specifying sets of links instead of inclusive docfypes 
(see transact.dtd for an example of this technique). These links bear attributes indicating 
whether the targets they point to are properly content of the parent document or lie 
outside of it. 

Each XML test file invokes one of the .mod or .dtd modules, without further declarations 
(no internal subsets allowed!) except for module tests, where other modules may need to 
be declared. 

The following test files have been used to exercise and validate (in the XML sense) the 
XML DTDs of CBL: 

• qcblcato.xml 

• qcomm.xnil 

• qentry.xml 

• qfuUcat.xml 

• qg.xml 

• qinfor.xml 

• qinvoice.xml 

• qinvetoy.xml 

• qmani.xml 

• qmark.xml 

• qmod.xml 

• qmdesc.xml 

• qord.xml 

• qots.xml 

• qpay.xml 

• qresp.xml 

• qrfq.xml 

• qsched.xml 

• qsem.xml 

• qservd.xml 

• qservm.xml 

• qship.xml 

• qshop.xml 

• qtaxo.xml 
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FPI for CBL 



A possible Formal Public Identifier (FPI) for all of CBL would be 

-//CNgroup//DTD CBL version 0.1//EN 

and for individual pieces, 

-//CNgroup//DTD CBL [module . name] version 0.1//EN 

where [module.name] is something like addresso.mod or markpart.dtd . 

Depending on the final state of the XML 1.0 specification, CBL DTDs may be referred to 
by means of URLs, FPIs, Pis (Public Identifiers), FPIs encoded as URNs, or URNs of 
some other sort. 

Older Documentation for CBL Components 

When CBL is complete, each component will have its own reference document (man 
page), formatted in HTML. For now, each component has a semantics file, with the same 
name as the component but ending in . sem. These files are XML instances conforming to 
semantic.dtd . For example, the aggtrans . dtd file is documented in the aggtrans . sem 
file. Every element type name, attribute name, and enumerated attribute value is defined 
in English. Where elements employ standardized semantics, the data types of their 
content and standardized attribute values are as specified in the applicable standard. 
Otherwise XML data typing has been eschewed except for enumerated lists of attribute 
values. As a result, except for certain obvious cases (a uriiink attribute should have a 
URL as its value), element content and attribute values are specified only as strings. 
(These specifications not updated after 0.5.) 

In addition, the following documentation is available: 

• doctrans.htm. documenting transact.mod 

• fixedvar.sem. documenting fixed attributes that appear with different values on 
different elements. 

• currlist.sem, documenting currency code values; these are not specified in 
currency . mod because there are too many of them, but this data dictionary 
fragment can be used for data type checking after XML parsing. 

CBL XML Design Preferences 

It helps to have a list of design preferences (similar to a style sheet) for a set of DTDs in 
order to maintain consistency among them. For CBL DTDs the following design 
preferences are in force: 
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• Use lowercase where uppercase is not required by XML. 

• Use periods for word dividers in NAME strings. 

• Do not abbreviate words in NAME strings except for "info". 

• Help avoid name space collisions by forcing enumerated lists into attribute value 
lists. 

• Group like names so they alphabetize well, e.g., date . calendar and 

date . ordinal. 

• Permit variants of element content where ISO, etc., standards allow optional 
punctuation. Data content validators must be capable of handling these variations. 

• No data attributes. 
. No NOTATIONS. 

• No marked sections, including CD ATA marked sections. 

• No embedding of scripts in comments. 

o No internal subsets: the active DTD must be identifiable by a URL or URN, so all 
declarations must be external. 

• No general entities aside from those defined by XML. 

• Try to provide default values for attributes instead of using #IMPLIED, when 
there is an enumerated list. 

• Follow the estabhshed naming conventions (should be listed) for element and 
attribute names, including strings "pointer", "set", and "attrib". 

• Assign no FPIs or URNs without consuhation. 

For instances, we want to make it a convention that elements declared EMPTY in a DTD 
may be represented only by the <element/> syntax, and that elements that may have 
content but happen not to may be represented only by the <eiement></element> syntax. 

CBL Design Rationale 

The design of CBL's XML is heavily influenced by the author's common sense, life 
experience, and experience in writing and using SGML DTDs. The UN/EDIFACT 
information typology has been used for the purpose of unifying the semantics of terminal 
elements. 

The MIME part of CBL is proposed in reaction to previous work on SGML and MIME in 
the IETF, and refines an earlier proposal by myself. I also learned much about MIME in 
the course of the OCLC's Metadata conference series, through discussion of Uniform 
Resource Characteristics in the IETF, and through a review of MIME specifications in 
November 1997. 
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Exhibit D. Selected files from cbl/072 directory (date stamped in 1997) 



• catentry.dtd Version: 0.6 — > 

■ Purpose: provide simplest catalogue entry --> 

■ Terry Allen 25 Nov 1997 — > 

■ Copyright 1997 CNgroup, Inc. — > 

SYSTEM "commatts .mod"> 



<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<!ENTITY % currency SYSTEM "currency .mod"> 



<! ENTITY % pointers SYSTEM "pointers .mod": 
%pointers; 

<! ENTITY % proddesc SYSTEM "proddesc .mod"; 
%proddesc; 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ENTITY % price SYSTEM "price. mod"> 
%price; 



<! ELEMENT catalogue . entry (meta?, market. participant. popular .name 
market .participant . info .pointer, catalogue . entry . id, 
product. description, max . quantity .per . customer? , stock. status? 
quantity . in . stock? , shipment . set . pointer? , 
payment .method. set .pointer? , price . group, 
picture .pointer*, html . catalogue . entry .pointer?) > 

<!ATTLIST catalogue. entry 
% common. attrib, • 
%ttl.attrib; 



<! ELEMENT catalogue . entry . id (%multilingual; ) *> 
<!ATTLIST catalogue. entry. id 
%common. attrib ; 



<! ELEMENT max . quantity . per . customer (#PCDATA)> 
< ! ATTLIST max . quantity . per . customer 
% common. attrib; 



<! ELEMENT picture . pointer (xll . locator ) > 
<! ATTLIST picture. pointer 

%common. attrib ; 

%xll.exlink. attrib; 

cblpointer CDATA #FIXED "outside" 
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<!-- cblcat.dtd Version: 0.6.1 — > 

<! — Purpose: associate local filenames /URLs with URNs 
<! — Terry Allen 27 Nov 1997 — > 

<! — developed from storage. dtd, for which the FPI is 

"-//Palm Tree Books//DTD USB-Storage v0.1//EN" — : 
<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<!ELEMENT cblcat {meta?, cblcat . entry .pointer+) > 
<!ATTLIST cblcat 
%common.attrib; 



<! ELEMENT cblcat . entry . pointer (catalogue . filename, 

(%xll.or.urn;) )> 
<!ATTLIST cblcat. entry. pointer 
%common.attrib; 



<! ELEMENT catalogue . filename (#PCDATA)> 
<!ATTLIST catalogue. filename 
%common.attrib; 
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— command . dtd Version: 0.7.2 — > 

— Purpose: group command informatioi 

— Terry Allen 5 Dec 1997 — > 

— Copyright 1997 CNgroup, Inc. — > 

SYSTEM "commatts .mod"; 



<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers ; 

<! ENTITY % command 

"convey. info | register . document | unregister . document 
I register . service | unregister . service | request . info" 



<! ELEMENT command. set (meta?, authorization. info. pointer*, 

{%command;), command. target) > 
<!ATTLIST command. set 

%common.attrib; 



<! ELEMENT convey. info EMPTY> 
<!ATTLIST convey. info 

%common.attrib; 

%party . attrib; 



<! ELEMENT register . document EMPTY> 
<!ATTLIST register .document 

%common. attrib ; 

%party. attrib; 



<! ELEMENT unregister . document EMPTY> 
<!ATTLIST unregister. document 

% common . attrib; 

%party. attrib; 



:! ELEMENT register. 
:!ATTLIST register. 

% common. attrib; 

%party. attrib; 



:! ELEMENT unregister. 
MATTLIST unregister. 

% common. attrib; 

%party. attrib; 



:! ELEMENT request. info EMPTY> 
:!ATTLIST request. info 
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%coinmon.attrib; 
%party . attrib,■ 



<!ELEMENT command. target { %xll . or . urn; ) > 
<!ATTLIST command. target 
%common. attrib; 



{00058300.DOC } 



<! — countrys .mod Version: 0.22 — > 

<! — Purpose: group country code tokens — > 

<!— Terry Allen 18 Oct 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 





country .nar 




rib 










.name 




AE 1 


AF 


AG 


AI 


AL 


AO 




AR 


AS 1 


AT 


AU 


AW 


AZ 


BA 


BB 


BD 


BE 1 


BF 


EG 


BH 




BJ 






BO 1 


BR 


BS 




BV 




BY 


BZ 








CG 


CH 


CI 






CM 1 


CN 


CO 


CR 


CU 


CV 




CY 


CZ 1 


DE 


DJ 


DK 


DM 


DO 


DZ 




EE 1 


EG 


EH 


ER 


ES 


ET 






FK 1 




FO 






GA 








GF 




GI 


GL 






GP 


GQ 1 


GR 


GS 


GT 


GU 


GW 


GY 


HK 
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HT 


HU 


ID 


IE 


IL 
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10 
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IR 
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IT 
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KN 


KP 
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LA 
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LI 


LK 1 


LR 
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LT 


LU 
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MA 
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MH 


ML 
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MO 
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MQ 


MR 


MS 


MT 


MU 
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MW 
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MY 


MZ 


NA 


NC 


NE 


1 NF 


NG 
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NL 


NO 


NP 


NR 


NT 
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NZ 
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PA 


PE 


PF 


PG 


PH 
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PL 
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PN 


PR 


PT 


PW 


PY 
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RE 
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RU 


RW 


SA 


SB 


SC 


1 SD 


SE 


SG 1 


SH 


SI 


SJ 


SK 


SL 


1 SM 


SN 


SO 1 


SR 


ST 


SV 


SY 


SZ 


1 TC 


TD 


TF 1 


TG 


TH 


TJ 


TK 


TM 


1 TN 


TO 


TP 1 


TR 


TT 


TV 


TW 


TZ 


1 UA 


UG 


UM 1 


US 


UY 


UZ 


VA 


VC 


1 VE 


VG 


VI 1 


VN 


VU 


WF 


WS 


YE 


1 YT 


YU 


ZA 1 


ZM 


ZR 


ZW) 


#REC 
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<! — currency .mod Version: 0.5 — > 
<!-- Purpose: group currency primitives 
<!— Terry Allen 24 Nov 1997 — > 
<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % currency. code. attrib 
"currency. code CDATA #REQUIRED" 



<!ELEMENT currency . amount (#PCDATA)> 
<!ATTLIST currency. amount 

schema :edif act CDATA #FIXED "currency" 

% currency . code . attrib; 



<! ELEMENT noncurrency . amount {# PCDATA )> 
<!ATTLIST noncurrency . amount 

unit CDATA #IMPLIED 

issuer CDATA #IMPLIED 
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<! — datetime .mod Version: 0.6 — > 

<! — Purpose: group date and time information primitives — > 
<!— Terry Allen 26 Nov 1997 — > 
<!— Copyright 1997 CNgroup, Inc. --> 

<!— checked against ISO 8601:1988 (E) 26 Nov 1997 by Terry Allen 

<! ELEMENT date {#PCDATA)> 
<!ATTLIST date 

schema :edif act CDATA #FIXED "date" 



<! ELEMENT date . calendar (#PCDATA)> 
<!ATTLIST date. calendar 

schema :iso8 601 CDATA #FIXED "3.3 date. 



:! ELEMENT date . ordinal (#PCDATA)> 
:!ATTLIST date. ordinal 

schema: iso8 601 CDATA #FIXED "5.2.2 ordinal date" 



:! ELEMENT time {#PCDATA)> 
MATTLIST time 

schema: iso8601 CDATA #FIXED "5.3 tii 



<! ELEMENT utc (#PCDATA)> 
<!ATTLIST utc 

schema :iso8 601 CDATA #FIXED "5.3.3 < 



<! ELEMENT week {#PCDATA)> 
<!ATTLIST week 

schema: iso8 601 CDATA #FIXED "5.2.3 \ 



<! ELEMENT week. and. day (#PCDATA)> 
<!ATTLIST week. and. day 

schema: iso8 601 CDATA #FIXED "5.2.3 date identified by 

calendar week and day numbers" 



<! ELEMENT date . and. time (#PCDATA)> 
<!ATTLIST date. and. time 

schema :edif act CDATA #FIXED "dateandtime" 

schema :iso8 601 CDATA #FIXED "5.4 combination of date and 

time of the day" 



<! ELEMENT duration (#PCDATA)> 

<!ATTLIST duration 

schema :edif act CDATA #FIXED "dateandtime" 
schema: iso8601 CDATA #FIXED "5.5.3.2 duratii 
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<!— guide, dtd Version: 0.6.2 — > 

<! — Purpose: group negotiation guide information — > 
<!— Terry Allen 29 Nov 1997 — > 
<!— Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common, • 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%polnters; 

<! ENTITY % negotiation. step. content "initiate | conclude | cancel 
I advance | modify | failure"> 

<! ENTITY % cbl. component 

"request . for . quote . component | request . for . info . component 
I response . component | market . description . component 
I catalogue . entry . component | catalogue . component 
I schedule . component | inventory . set . component 
I of fer. to . sell . component 

I market. participant. info. component | shopping . cart . component 
I order . component | invoice . component 

I payment .notice . component | shipment .notice . component 

I service . description . component | server .metadata . component 

I confirm. component 

I acknowledge. previous. component | escape . component" 



<! ELEMENT guide (meta?, negotiation . identifier* , 
authorization . info . pointer* , 
negotiation. step, process .model) > 

<!ATTLIST guide 
%common.attrib; 



<! ELEMENT negotiation . identifier (#PCDATA)> 
<!ATTLIST negotiation. identifier 

%common.attrib; 

%party . attrib; 



<! ELEMENT negotiation 
<!ATTLIST negotiation 

% common. attrib; 

%party .attrib ; 



<! ELEMENT initiate EMPTY> 
<!ATTLIST initiate 
% common. attrib ; 



<! ELEMENT conclude EMPTY> 
<!ATTLIST conclude 



.step {%negotiation. step. content; ) > 
. step 
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! ELEMENT advance EMPTY> 
:!ATTLIST advance 
%coinmon. attrib; 



! ELEMENT cancel EMPTY> 
lATTLIST cancel 
%coitimon . attrib; 



! ELEMENT failure EMPTY> 
lATTLIST failure 
%common. attrib ; 



:! ELEMENT modify (modification . set .pointer* ) > 
: lATTLIST modify 

%common. attrib ; 

%party. attrib; 



:! ELEMENT cbl . component . group ( %cbl . component; ) + 
; lATTLIST cbl . component . group 

% common. attrib; 

%party . attrib; 



1 ENTITY % cbl . component . or . group 

"%cbl . component; | cbl . component . group" 



;1ELEMENT process .model ({ %cbl . component . or . group; 

{%cbl . component . or . group; ) * ) > 
; lATTLIST process .model 

%common. attrib; 



1 ENTITY % component. attrib 

"schema. name (cbl | noncbl) 'cbl'' 



1 ENTITY % cbl. component. contents 

"document. pointer*, originating. party?, receiving. party*' 



lELEMENT originating . party (market .participant . info . pointer ) > 
lATTLIST originating. party 
I. attrib; 



<1ELEMENT receiving . party (market .participant . info .pointer ) > 
< lATTLIST receiving. party 
% common. attrib; 
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<! ELEMENT confirm. component ( %cbl . component . contents ;) > 
<!ATTLIST confirm. component 

%common.attrib; 

%component . attrib; 

%partY. attrib; 

confirming CDATA #REQUIRED 



< ! ELEMENT acknowledge . previous . component ( %cbl . component . contents ; ) > 
< ! ATTLIST acknowledge .previous . component 

% common. attrib ; 

% component . attrib; 

%party. attrib; 



< ! ELEMENT request . for . quote . component ( %cbl . component . contents ; ) > 
< ! ATTLIST request . for . quote . component 

% common. attrib; 

%component . attrib; 

%party. attrib; 



< ! ELEMENT request . for . info . component { %cbl . component . contents ; ) > 
< ! ATTLIST request . for . info . component 

%common. attrib; 

%component . attrib; 

%party. attrib; 



<! ELEMENT response . component ( %cbl . component . contents ;) > 
<! ATTLIST response. component 

%common. attrib; 

% component . attrib; 

%party .attrib ; 



<! ELEMENT of fer . to . sell . component ( %cbl . component . contents; ) > 
<! ATTLIST of fer. to. sell. component 

% common. attrib; 

% component . attrib; 

%party. attrib; 



< ! ELEMENT catalogue . entry. component ( %cbl . component . contents; ) > 
< ! ATTLIST catalogue . entry. component 

%common. attrib; 

%component . attrib; 

Iparty. attrib; 



<! ELEMENT catalogue . component ( %cbl . component . contents; ) > 
<! ATTLIST catalogue . component 

% common. attrib; 

% component . attrib; 

%party. attrib; 
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<! ELEMENT schedule . component { %cbl . component . contents; ) > 

<!ATTLIST schedule. component 
%common.attrib; 
%component . attrib; 
%party . attrib; 



; ! ELEMENT market . participant . info . component ( %cbl . component . contents 
; ! ATTLIST market . participant . info . component 
%common. attrib ; 



% component . attr 
%party .attrib ; 



C ! ELEMENT shopping . cart . component ( %cbl . component . i 
: ! ATTLIST shopping . cart . component 

%common. attrib; 

% component . attrib; 

%party. attrib; 



:! ELEMENT order . component ( %cbl . component . contents ;) > 
:! ATTLIST order. component 

% common. attrib; 

% component . attrib; 

%party . attrib ; 



:! ELEMENT invoice . component ( %cbl . component . contents, 
:! ATTLIST invoice. component 
n. attrib; 



% component . attrib; 
%party. attrib; 

;! ELEMENT payment . notice . component ( %cbl . component . contents ; 
; ! ATTLIST payment . notice . component 

% common. attrib; 

% component . attrib; 

%party. attrib; 



: ! ELEMENT shipment . notice . component ( %cbl . component . contents ; ) > 
;! ATTLIST shipment .notice . component 

% common. attrib; 

% component . attrib; 

%party. attrib; 



: ! ELEMENT service . description . component (%cbl . component . contents; 
: ! ATTLIST service . description . component 

%common. attrib; 

%component . attrib; 

%party . attrib ; 
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<!ELEMENT server .metadata . component (%cbl . component . contents; ) > 
< ! ATTLIST server .metadata . component 

%common.attrib; 

% component . attrib; 

%party.attrib; 



< ! ELEMENT market . description . component ( %cbl . component . contents ; ) 

< ! ATTLIST market . description . component 
%mimetype. attrib ; 
%common.attrib,• 
%component . attrib; 
%party. attrib; 



<! ELEMENT inventory . set . component { %cbl . component . contents ;) > 
< ! ATTLIST inventory . set . component 

%mimetype .attrib ; 

%common . attrib; 

%component . attrib; 

%party .attrib ; 



<! ELEMENT escape . component ( %cbl. component. contents; ) > 
<! ATTLIST escape. component 

%mimetype . attrib ; 

%common. attrib; 

%component . attrib; 

%party. attrib; 



<! ELEMENT we. are. here EMPTY> 
<! ATTLIST we. are. here 

% common. attrib; 

%party. attrib; 
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! — inf odesc .mod Version: 0.6.2 — > 

! — Purpose: supply structure for all descripti( 

CBL XML documents — > 
!— Terry Allen 29 Nov 1997 — > 
!-- Copyright 1997 CNgroup, Inc. --> 

! ENTITY % infodesc.or.set 

" (info .description | inf o . description . set ) " 



! ELEMENT inf o . description . set (%inf odesc 
{(and, %infodesc.or. set; ) * 
I (or, %infodesc.or.set; ) * 
I (not, %inf odesc. or . set; ) ) 



MATTLIST info. description. set 
%common.attrib; 



:! ELEMENT and EMPTY> 
:!ATTLIST and 

%common. attrib; 



:! ELEMENT or EMPTY> 
MATTLIST or 

%common. attrib; 



:! ELEMENT not EMPTY> 
:!ATTLIST not 

attrib; 



:! ELEMENT inf o . description (xml . descriptor | nonxml . descripto: 

I urn. reference | regexp | range )> 
:!ATTLIST info .description 

%common. attrib; 



:! ELEMENT xml . descriptor (doctype, xml . descriptor . details ) > 
:!ATTLIST xml. descriptor 
%common. attrib; 



:! ELEMENT nonxml . descriptor ( %xll . or . urn; ) > 
:!ATTLIST nonxml .descriptor 
% common. attrib; 

cblpointer CDATA #FIXED "outside" 



:! ELEMENT regexp (#PCDATA)> 
:!ATTLIST regexp 
%common. attrib; 



:! ELEMENT doctype {dtd)> 
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:!ATTLIST doctype 
%common. attrib; 



■!ELEMENT dtd EMPTY> 
lATTLIST dtd 

systemid CDATA # IMPLIED 
publlcid CDATA #IMPLIED 
L.attrib; 



;! ELEMENT xml . descriptor . details (xml . descriptor . context? 

(xll . xptr . f rag | xml . other . descriptor )) > 
; lATTLIST xml. descriptor. details 
..attrib; 



<! ELEMENT xml . descriptor . context EMPTY> 
< lATTLIST xml. descriptor. context 
%common. attrib ; 

xll . link. traverse (none | all | all.recurse) "all . recurse" 



<! ELEMENT xml . other . descripto: 
< lATTLIST xml. other .descripto: 

% common. attrib; 

type CDATA #REQUIRED 



:! ELEMENT range (range .parameter, range .parameter, range .parametei 
: lATTLIST range 

schema. name CDATA #IMPLIED 

%common . attrib ; 



:! ELEMENT range . parameter (#PCDAT2 
: lATTLIST range. parameter 

range. type (integer | decimal 
schema. mapping CDATA #IMPLIED 
n. attrib ; 
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<!-- inventory. dtd Version: 0.6 — > 

<!-- Purpose: provide inventory information --> 

<!-- Terry Allen 25 Nov 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % coitimon SYSTEM "commatts .mod"> 
%common; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % currency SYSTEM "currency .mod"> 
%currency; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 

<! ENTITY % proddesc SYSTEM "proddesc .mod"> 
%proddesc; 

<! ENTITY % meta SYSTEM "meta .mod"> 
%meta; 

<! ENTITY % price SYSTEM "price .raod"> 
%price; 

<!ELEMENT inventory . set (meta?, inventory . item+) > 
<!ATTLIST inventory. set 

%common.attrib; 

%ttl.attrib; 



<! ELEMENT inventory . item (market .participant . info .pointer+, 
inventory. id, product . description, stock . status? , 
quantity. in. stock? ) > 

<!ATTLIST inventory. item 
% common. attrib, • 
%ttl.attrib; 



<!ELEMENT inventory. id (%multilingual; ) *> 
<!ATTLIST inventory. id 
%common. attrib; 
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<!-- manifest. dtd Version: 0.7.1 — > 

<! — Purpose: packing list for MIME message — > 

<! — Based on package. dtd from Terry Allen's 

"Unoptimized SGML-Bundle for MIME" proposal of February 

or March 1997, "-//Palm Tree Books//DTD USB-Package v0.1//EN" — > 

<! — Terry Allen 4 Dec 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % manifest. ids. attrib 
"cidofpart CDATA #IMPLIED 
urnofentity CDATA #IMPLIED 
cidofentity CDATA #IMPLIED" 



<! ELEMENT manifest ( (mime . docentity. pointer | external . docentity.pointc 
(mime . sgmldecl .pointer | external . sgmldecl .pointer )* , 
(mime . catalogue .pointer? | external . catalogue .pointer? ) , 
(mime .dtd. module .pointer | external . dtd. module .pointer )* , 
(mime . other . entity .pointer | external . other . entity .pointer )*) > 

<! ELEMENT mime . docentity . pointer EMPTY> 
<!ATTLIST mime. docentity. pointer 
%manif est . ids . attrib; 



<! ELEMENT external . docentity . pointer EMPTY> 
< ! ATTLIST external . docentity . pointer 
%manif est . ids . attrib; 



<! ELEMENT mime . sgmldecl . pointer EMPTY> 
<! ATTLIST mime. sgmldecl. pointer 
%manif est . ids . attrib; 



<! ELEMENT external . sgmldecl . pointer EMPTY> 
< ! ATTLIST external . sgmldecl . pointer 
%manif est . ids . attrib; 



<! ELEMENT mime . catalogue . pointer EMPTY> 
<! ATTLIST mime. catalogue. pointer 
%manif est . ids . attrib; 



<! ELEMENT external . catalogue . pointer EMPTY> 
< ! ATTLIST external . catalogue . pointer 
%manif est . ids . attrib ; 



<! ELEMENT mime . dtd. module .pointer EMPTY> 
< ! ATTLIST mime . dtd. module .pointer 
%manifest . ids . attrib; 



<! ELEMENT external . dtd. module .pointer EMPTY> 
< ! ATTLIST external . dtd . module . pointer 
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ismanif est . ids . attrib; 



<! ELEMENT mime . other . entity . pointer EMPTY> 
< ! ATTLIST mime . other . entity . pointer 
%manif est . ids . attrib; 



<! ELEMENT external . other . entity . pointer EMPTY> 
< ! ATTLIST external . other . entity . pointer 
%manif est . ids . attrib; 
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<! — markdesc.dtd Version: 0.6 — > 
<! — Purpose: describe a marketplace — > 
<!-- Terry Allen 25 Nov 1997 — > 
<!-- Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common ; 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<!ENTITY % currency SYSTEM "currency .mod"> 
%currency; 

<! ENTITY % price SYSTEM "price. mod"> 

<! ENTITY % countrys SYSTEM "countrys .mod"> 
%countrys; 

<! ENTITY % payment SYSTEM "paymento.mod"> 
%payment; 

<! ENTITY % shipment SYSTEM "shipment .mod"> 
% shipment; 

<! ENTITY % address SYSTEM "addresso .mod"> 
%address; 

<! ENTITY % servprim SYSTEM "servprim.mod"> 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ENTITY % transact SYSTEM "transact .mod"> 
%transact; 

<! ELEMENT market . description (market . name, 

market, id?, market . operators-, market . registry+, 
market . terms . pointer ) > 

<!ATTLIST market. description 
% common. attrib, • 
%ttl.attrib; 



<!ELEMENT market. name {%multilingual; ) *> 
<!ATTLIST market. name 
% common. attrib ; 
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<! ELEMENT market . id (%multilingual; ) *> 
<!ATTLIST market. id 
..attrib; 



<! ELEMENT market . operator (market . operate 

market . participant . info . pointer) > 
<!ATTLIST market. operator 
1. attrib ; 



<!ELEMENT market . operator . name ( %multilingual; ) * 
<!ATTLIST market. operator .name 
..attrib; 



:! ELEMENT market . registry (market. registry. name, 

market. registry. id?, registry . role, service . location. pointer+) 
:!ATTLIST market. registry 

%common. attrib; 

%ttl. attrib; 



C! ELEMENT market . registry . name (%multilingual; ) *> 
ClATTLIST market. registry. name 
% common . attrib; 

;!ELEMENT market . registry . id ( %multilingual; ) *> 
ClATTLIST market. registry. id 
% common . attrib; 

:! ELEMENT registry . role EMPTY> 
ClATTLIST registry. role 

registry. contents (vendors | buyers | shippers) #REQUIRED 
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■ markpart . dtd Version: 0.7.2 — > 

■ Purpose: groups market participant information - 

■ Terry Allen 5 Dec 1997 — > 

■ Copyright 1997 CNgroup, Inc. — > 

[TITY % common SYSTEM "commatts .mod"> 



<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % countrys SYSTEM "countrys .mod"> 
%countrys; 

<! ENTITY % addresso SYSTEM "addresso .mod"> 
%addresso; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 



<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ENTITY % servprim SYSTEM "servprim.mod"> 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 



<!ELEMENT market . participant . info (meta?, (company . info | personal . info) , 

service. list? )> 
< ! ATTLIST market . participant . info 

%common.attrib; 

%ttl.attrib; 



<! ELEMENT company. info {company. name, previous .name*, 

(duns |duns4 |mall . assigned) , business . code* , 

start. date?, incorporated. in?, 

company. superentities? , company. subentities? , 

company . affiliation? , contact+)> 
<! ATTLIST company. info 

% common . attrib; 

%ttl.attrib; 



<! ELEMENT personal. info (personal .name, address . sett) > 
<! ATTLIST personal. info 
% common. attrib; 



<!ELEMENT business . code (naics.code | isic.code | j isx0403 . code) > 
<! ATTLIST business. code 
% common . attrib; 



<! ELEMENT naics.code EMPTY> 
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:!ATTLIST naics.code 
%common.attrib; 

schema males CDATA #REQUIRED 



<! ELEMENT isic.code EMPTY> 
<!ATTLIST isic.code 
% common. attrib, • 

schema :isic CDATA #REQUIRED 



<! ELEMENT j isx0403 . code EMPTY> 
<!ATTLIST jisx0403.code 
%common. attrib; 

schema: jlsx0403 CDATA #REQUIRED 



[ELEMENT company. name ( %multilingual; ) *> 
lATTLIST company. name 
% common. attrib; 

schema :edif act CDATA #FIXED "organizat 



:! ELEMENT previous . name {%multilingual; ) 
: lATTLIST previous .name 
n. attrib; 



:! ELEMENT duns (#PCDATA)> 
: lATTLIST duns 

attrib; 



<! ELEMENT duns4 {#PCDATA)> 
< lATTLIST duns4 

n. attrib; 



:! ELEMENT mall. assigned (#PCDATA)> 
: lATTLIST mall. assigned 
%common. attrib; 



<1 ELEMENT naics (#PCDATA)> 
< lATTLIST naics 
%common. attrib; 



:l ELEMENT isic {#PCDATA): 
: lATTLIST isle 

n. attrib; 



:! ELEMENT fsc (#PCDATA)> 
: lATTLIST fsc 

n. attrib; 



{00058300.DOC ) 



22 



:! ELEMENT start. date (date)> 
MATTLIST start. date 
% common . attrib; 



<!ELEMENT incorporated. in (country, country. subentity?) > 
<!ATTLIST incorporated. in 
% common. attrib; 



lELEMENT company . superentities { super entityt) > 
lATTLIST company. superentities 
%common. attrib; 



<!ELEMENT company . subentities { subentity+) > 
< lATTLIST company. subentities 
% common. attrib; 



c lELEMENT company . affiliation {#PCDATA)> 
c lATTLIST company. affiliation 
L. attrib; 



;!ELEMENT superentity { company . name, company . info . pointer? , 

company. superentities? ) > 
: lATTLIST superentity 

% common . attrib; 



: lELEMENT subentity {company. name, company . info . pointer? , 

company . subentities ? ) > 
lATTLIST subentity 
L. attrib; 



: I ELEMENT contact (contact . function* , personal . name* , 
language . understood* , 

occupation. title?, occupation. code?, address . sett) > 
: lATTLIST contact 
attrib; 



: I ELEMENT contact . function { %multilingual ; ) * 
: lATTLIST contact. function 
attrib; 



: I ELEMENT language . understood EMPTY> 
: lATTLIST language .understood 
%lang . attrib . required; 
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<! — modify. dtd Version: 0.6.2 — > 

<! — Purpose: group negotiation guide informatii 

<!— Terry Allen 29 Nov 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common ; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % meta SYSTEM "meta.mod"> 



<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 

<! ELEMENT modification. set (meta?, modificatic 
original . document .pointer, 

modified. document . pointer, modification* ) > 
<!ATTLIST modification. set 
%common. attrib; 
%party . attrib; 



<!ELEMENT modification. reason EMPTY> 
<!ATTLIST modification. reason 
%common.attrib; 

reason (product . substitution | price. change | quantity . change 
I tpa. change | self . explanatory) "self-explanatory'' 



<! ELEMENT original . document (document .pointer) > 
<!ATTLIST original. document 
%common.attrib; 



:! ELEMENT modified . document (document .pointer) > 
:!ATTLIST modified. document 
attrib; 



:! ELEMENT modification (change.pointer . set | disagree . pointer 

I agree. pointer. set | prefer .pointer . set) *> 
:!ATTLIST modification 

% common. attrib; 

%party . attrib ; 



:! ELEMENT change . pointer . set (change .pointer+) > 
:!ATTLIST change.pointer . set 

%common. attrib; 

%party . attrib; 



:!ELEMENT change.pointer (changed. from. pointer, changed. to . pointer ) > 
:!ATTLIST change.pointer 
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; common. attrib; 



<!ELEMENT changed . from. pointer ( %xll . or . urn; ) > 
<!ATTLIST changed. from. pointer 
%common. attrib; 

cblpointer CDATA #FIXED "outside" 



<!ELEMENT changed. to .pointer { %xll . or . urn; ) > 
<!ATTLIST changed. to. pointer 
% common. attrib; 

cblpointer CDATA #FIXED "outside" 



<!ELEMENT disagree . pointer . set (disagree . pointe 
<!ATTLIST disagree. pointer. set 

% common. attrib; 

%partY .attrib ; 



<! ELEMENT disagree . pointer { %xll . or . urn; ) > 
<!ATTLIST disagree .pointer 
% common. attrib; 

cblpointer CDATA #FIXED "outside" 



<!ELEMENT prefer . pointer . set (prefer . pointer+) > 
<!ATTLIST prefer .pointer. set 

%common. attrib; 

%party. attrib; 



<! ELEMENT prefer . pointer (%xll.or .urn; ) > 
<!ATTLIST prefer .pointer 

% common. attrib; 

degree CDATA "0" 

cblpointer CDATA #FIXED "outside" 
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<!-- ots.dtd Version: 0.1 — > 

<! — Purpose: define basic Offer To Sell ■ 

<!— Terry Allen 2 Nov 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common ; 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 



meta SYSTEM ' 



<! ENTITY % currency SYSTEM "currency .mod"> 
%currency; 

<! ENTITY % price SYSTEM "price. mod"> 
%price; 



<! ENTITY % proddesc SYSTEM "proddesc .mod"> 
%proddesc; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 



<! ELEMENT of f er . to . sell (meta?, 

(market. participant. info. pointer | personal . info . pointer ) , 

xml . catalogue . pointer ) > 
<!ATTLIST offer. to. sell 

%common.attrib; 

%ttl.attrib; 
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■ paymento .mod Version: 0.5 — > 

■ Purpose: group payment primitives ■ 

■ Terry Allen 9 Nov 1997 — > 

• Copyright 1997 CNgroup, Inc. — > 

ITITY % issuer. name. attrib 
'issuer. name CDATA #REQUIRED" 



<! ELEMENT payment .method. set {payment .method+) > 
<!ATTLIST payment. method. set 
n. attrib; 



:! ELEMENT payment .method (cash | credit. card | debit. card 

I check I eurocheck | bank . wire . transfer 

I postal. wire. transfer | ecash)> 
lATTLIST payment. method 

% common .attrib ; 



:! ELEMENT cash EMPTY> 
:!ATTLIST cash 

%currency . code . attrib ; 



:! ELEMENT credit. card EMPTY> 
:!ATTLIST credit. card 
%issuer . name . attrib; 



:! ELEMENT debit . card EMPTY> 
:!ATTLIST debit. card 
%i s suer . name .attrib ; 



! ELEMENT check EMPTY> 
lATTLIST check 

%currency . code . attrib; 

% country .name . attrib; 



:! ELEMENT eurocheck EMPTY> 
: lATTLIST eurocheck 
%issuer .name . attrib; 



;! ELEMENT bank . wire . transfer EMPTY> 
: lATTLIST bank. wire. transfer 

agent. name CDATA #REQUIRED 



;l ELEMENT postal. w 
:1ATTLIST postal. w 
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<! ELEMENT ecash EMPTY> 
<!ATTLIST ecash 

%currency . code . attrib; 

%issuer . name . attrib; 



<! ELEMENT monetary . payment (currency . amount) > 
<!ATTLIST monetary. payment 
%common . attrib; 
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■ paynoteo.dtd Version: 0.5 --> 

• Purpose: describe a payment notice-- 

■ Terry Allen 9 Nov 1997 — > 

• Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common; 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 



<! ENTITY % currency SYSTEM "currency .mod"> 
%currency; 

<! ENTITY % price SYSTEM "price. mod"> 

<! ENTITY % countrys SYSTEM "countrys .mod"> 
% country s; 

<! ENTITY % payment SYSTEM "paymento .mod"> 
%payment; 

<! ENTITY % shipment SYSTEM "shipment .mod"> 
% shipment ; 

<! ENTITY % address SYSTEM "addresso .mod"> 



<! ENTITY % pointers SYSTEM "pointers .mod": 
%pointers; 

<! ENTITY % meta SYSTEM "meta.mod"> 



<!ELEMENT payment . notice (meta?, payment .method, monetary .payment, 

payor, payee, date . and. time) > 
<!ATTLIST payment. notice 

%common.attrib; 

%ttl.attrib; 



<! ELEMENT payor {market. participant. info. pointer | personal . info . point 
<!ATTLIST payor 
%coinmon.attrib; 



<! ELEMENT payee {market .participant . info .pointer | personal . info .point 
<!ATTLIST payee 
% common. attrib; 
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<! — price. mod Version: 0.5 --> 

<! — Purpose: group address information primitives — > 
<!— Terry Allen 8 Nov 1997 — > 
<!— Copyright 1997 CNgroup, Inc. — > 

<!ELEMENT price . group (base. price?, price .with . tax? , discount . set? , 
discounted. price?, price . adjust*, 

adjusted. price?, ship . charge . set? , total. price?) > 
<!ATTL1ST price. group 
%common.attrib; 
%ttl.attrib; 



<! ELEMENT base. price { currency . amount) > 
<!ATTLIST base. price 

% common. attrib, • 

%ttl.attrib; 

tax. included (yes | no) "no" 



<! ELEMENT price . with . tax (currency. amount) > 
<!ATTLIST price. with. tax 

% common .attrib ; 

%ttl. attrib; 



<! ELEMENT discount. set (di; 

<!ATTLIST discount. set 
% common. attrib , • 
%ttl.attrib,• 



<!ELEMENT discount (discount. name?, discount . id? , 
discount . rate?, discount . amount?) > 

<!ATTLIST discount 
% common. attrib; 
%ttl. attrib; 



<!ELEMENT discount . name ( %multilingual; ) *> 
<!ATTLIST discount. name 

% common. attrib; 

%ttl. attrib; 



<! ELEMENT discount. id (%multilingual; ) *> 
<!ATTL1ST discount. id 

%common. attrib; 

%ttl. attrib; 



<! ELEMENT discount . rate (rate)> 
<!ATTLIST discount. rate 

% common. attrib; 

%ttl. attrib; 
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;! ELEMENT rate (#PCDATA)> 
MATTLIST rate 

%common.attrib; 

%ttl.attrib; 

rate. basis (percent | other ) "pen 



:!ELEMENT discounted . price ( currency. amount) > 
:!ATTLIST discounted. price 

% common. attrib; 

%ttl.attrib; 



<! ELEMENT discount . amount (c 
<!ATTLIST discount. amount 
% common. attrib ; 
%ttl.attrib; 



:!ELEMENT price. adjust (tax. set?, other . charge . set? ) > 

;!ATTLIST price. adjust 
% common. attrib, • 
%ttl.attrib; 



:!ELEMENT adjusted . price (currency . amount) > 
:!ATTLIST adjusted. price 

% common. attrib; 

%ttl. attrib; 



:! ELEMENT tax. set {tax+)> 
:!ATTLIST tax. set 

% common. attrib; 

%ttl. attrib; 



:! ELEMENT tax (tax. name?, tax. id?, tax. rate?, tax . amount? ) > 
:!ATTLIST tax 

%common. attrib; 

%ttl. attrib; 



: ! ELEMENT tax . name ( %multilingual ; ) * 
:!ATTLIST tax. name 

%common. attrib; 

%ttl. attrib; 



;! ELEMENT tax. id ( %multilingual; ) *> 
;!ATTLIST tax. id 

% common. attrib; 

%ttl. attrib; 
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% common. attrib, • 
%ttl.attrib; 



<! ELEMENT tax. amount { currency. amount ) > 
<!ATTLIST tax. amount 

% common. attrib , • 

%ttl. attrib; 



<! ELEMENT other . charge . set (other . charge+) > 
<!ATTLIST other. charge. set 

%common. attrib , • 

%ttl. attrib; 



<! ELEMENT other. charge (other . charge .name?, 

other . charge . id?, other . charge . rate? , other . charge . amount) > 
<!ATTLIST other. charge 

% common. attrib; 

%ttl. attrib; 



:! ELEMENT other . charge . name (%i 
:!ATTLIST other. charge. name 

% common. attrib; 

%ttl. attrib; 



<! ELEMENT other . charge . id ( %multilingual; ) *> 
<!ATTLIST other. charge. id 

%common. attrib; 

%ttl. attrib; 



:! ELEMENT other . charge . rate {rate)> 
:!ATTLIST other. charge. rate 

% common. attrib; 

%ttl. attrib; 



<! ELEMENT other . charge . amount (currency . amount) > 
<!ATTLIST other . charge . amount 

% common. attrib; 

%ttl. attrib; 



<! ELEMENT ship . charge . set ( ship . charge+) > 
<!ATTLIST ship. charge. set 

% common. attrib; 

%ttl. attrib; 



<! ELEMENT ship. charge ( ship . charge . name? , 
ship . charge . id? , ship . charge . amount ) > 

<!ATTLIST ship. charge 
% common. attrib; 
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%ttl.attrib; 



<! ELEMENT ship . charge . name (%multilingual; 
<!ATTLIST ship . charge . name 

% common. attrib, • 

%ttl.attrib; 



:! ELEMENT ship . charge . id ( %multilingual; ) * 
MATTLIST ship. charge. id 

%common. attrib , • 

%ttl. attrib; 



:! ELEMENT ship . charge . amount (currency. ^ 
:!ATTLIST ship . charge . amount 

%common. attrib , • 

%ttl. attrib; 



:! ELEMENT total. price ( currency . amount ) > 
:!ATTLIST total. price 

% common. attrib; 

%ttl. attrib; 



:! ELEMENT total . discount ( 
;!ATTLIST total. discount 

% common. attrib; 

%ttl. attrib; 



:! ELEMENT total . adj ustment (currency . amount) > 
:!ATTLIST total. adj ustment 

%common. attrib; 

%ttl. attrib; 



! ELEMENT grand . total . price (currency . amount) > 
lATTLIST grand. total. price 

% common. attrib; 

%ttl. attrib; 



< ! ELEMENT price . range (minimum? , 
< lATTLIST price. range 

% common. attrib; 

%ttl. attrib; 



<! ELEMENT minimum (currency . amount) > 
< lATTLIST minimum 

%common. attrib; 

%ttl. attrib; 
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<! ELEMENT maximum (currency . amount) 
<!ATTLIST maximum 

% common. attrib, • 

%ttl.attrib; 
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<! — proddesc.mod Version: 0.6 — > 

<! — Purpose: provide simplest product description chunk — 

<!— Terry Allen 26 Nov 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 

<!ELEMENT product . description (product .name?, product. id*, 
product . line? , brand?, catalogue . category? , keyword. set, 
material. set?, color. set?, size. set*, warranty?, 
text. description) > 

<!ATTLIST product. description 
%common.attrib; 
%ttl.attrib; 



<! ELEMENT short . product . description (product . name? , product. 

product . line? , brand?, catalogue . category? , 

material . choice? , color . choice? , size . choice? ) > 
< ! ATTLIST short .product .description 

% common. attrib; 

%ttl.attrib; 



< ! ELEMENT product . name ( %multilingual ; ) * 
<! ATTLIST product. name 
% common. attrib ; 



<!ELEMENT product . id ( %multilingual; ) *> 
<! ATTLIST product. id 

% common. attrib ; 

type (upc I other) #IMPLIED 

assigned. by 

(manufacturer | distributor | vendor | nother) #IMPLIED 



<! ELEMENT product . line (%multilingual; ) *> 
<! ATTLIST product. line 
% common. attrib ; 



<!ELEMENT brand (%multilingual; ) *> 
<! ATTLIST brand 
% common. attrib ; 



<! ELEMENT catalogue . category (taxon.pointer+) > 
<! ATTLIST catalogue. category 
%common. attrib ; 



:! ELEMENT keyword. set 
:! ATTLIST keyword. set 
%common. attrib; 



<! ELEMENT keyword (#PCDATA)> 
<! ATTLIST keyword 
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% common. attrib; 
taxonomy CDATA # IMPLIED 



;!ELEMENT text . description (%multilingual; ) * 
;!ATTLIST text. description 
%common. attrib ; 



:! ELEMENT material . set (material+)> 
:!ATTLIST material. set 
% common. attrib ; 

conjunction (combination | alter 



:! ELEMENT material . choice (mate: 
;!ATTLIST material. choice 
n. attrib ; 



:!ELEMENT material { %multilingual; ) *> 
:!ATTLIST material 
%common. attrib ; 



:! ELEMENT color. set (color+)> 
;!ATTLIST color. set 
% common. attrib ; 

conjunction (combination | alternatives) 



:! ELEMENT color. choice (c^ 
:!ATTLIST color. choice 
attrib; 



; ! ELEMENT color { %multilingual ; ) * 
:!ATTLIST color 

n. attrib ; 



:! ELEMENT size. set ( size . qualifier? , 
MATTLIST size. set 

%coramon. attrib; 

units CDATA #REQUIRED 



MELEMENT size. choice {size)> 
MATTLIST size. choice 
n. attrib; 
CDATA #REQUIRED 



:! ELEMENT size . qualifier ( %multilingual; ) * 
MATTLIST size. qualifier 
%common. attrib; 
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<! ELEMENT size (%multilingual; ) *> 
<!ATTLIST size 

%common.attrib; 



<!ELEMENT warranty (%multilingual; ) *> 
<!ATTLIST warranty 
%common. attrib; 



<!ELEMENT stock. status EMPTY> 
<!ATTLIST stock. status 
%comraon. attrib; 
in.stock (yes I no) "yes" 
%ttl.attrib; 



<! ELEMENT quantity . in . stock (#PCDATA) 
<!ATTLIST quantity. in. stock 
%common.attrib; 
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! — response .dtd Version: 0.23 — > 

! — Purpose: define response to query. dtd - 

!— Terry Allen 26 Oct 1997 — > 

!— Copyright 1997 CNgroup, Inc. — > 

! ENTITY % common SYSTEM "commatts .mod"> 



: SYSTEM "datetii 



<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ELEMENT response (meta?, input .pointer, 

(error .response | success . response | delay . responsi 
record . pointer* ) > 
<!ATTLIST response 
n.attrib; 



:! ELEMENT input . pointer ( %xll . or . urn; ) > 
:!ATTLIST input. pointer 

%common.attrib; 

%xll.exlink.attrib; 

cblpointer CDATA #FIXED "content" 
target. dtd CDATA #FIXED "inf odesc . dtd" 



:! ELEMENT error . response EMPTY> 
MATTLIST error .response 
%common. attrib; 

type {unspecified | unauthorized | returntype .mismatch) 
#REQOIRED 



:! ELEMENT success . response EMPTY> 
MATTLIST success . response 
%common. attrib ; 



:! ELEMENT delay . response (date . and. time | duration) > 
MATTLIST delay. response 
% common. attrib; 



:! ELEMENT record . pointer {%xll.o 
MATTLIST record. pointer 

% common . attrib; 

%xll . exlink. attrib; 

cblpointer CDATA #FIXED 
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<!— rfq.dtd Version: 0.1 — > 

<! — Purpose: define basic Request for Quote — > 

<!— Terry Allen 2 Nov 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 



<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ENTITY % currency SYSTEM "currency .mod"> 
%currency; 

<! ENTITY % price SYSTEM "price. mod"> 
%price; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % proddesc SYSTEM "proddesc .mod"> 
%proddesc; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 



<! ELEMENT request . for . quote (meta?, 

(market. participant. info. pointer | personal . info .pointer 

desideratum+) > 
<!ATTLIST request. for. quote 

%common.attrib; 

%ttl.attrib; 



<! ELEMENT desideratum (product . description, price . range? ) > 

<!ATTLIST desideratum 
% common. attrib, • 
%ttl.attrib; 
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• semantic. dtd Version: 0.2 — > 

■ Purpose: group semantics for DTDs 

■ Terry Allen 15 Oct 1997 — > 

• Copyright 1997 CNgroup, Inc. — > 

ITITY % common SYSTEM "commatts .mod"> 



:!ELEMENT fpi (name, { (commonatts?, element*) | code. list) )> 
:!ATTLIST fpi 

n.attrib; 



:! ELEMENT name {#PCDATA)> 
:!ATTLIST name 

L.attrib;- 



;! ELEMENT commonatts (attribute+) > 
;!ATTLIST commonatts 
%common. attrib; 



:!ELEMENT element (name, meaning, attribute* )> 
:!ATTLIST element 
%common. attrib; 



< ! ELEMENT meaning ( %multilingual ; ) * 
<!ATTLIST meaning 
%common . attrib; 



:! ELEMENT attribute (name, meaning, def . list . item* , 

(default I fixed | implied | required) ) > 
;!ATTLIST attribute 
..attrib; 



<! ELEMENT def . list . item (name, meaning) > 
<!ATTLIST def .list. item 
..attrib; 



lELEMENT default (name)> 
lATTLIST default 
% common. attrib; 



:!ELEMENT fixed ((name?, meaning)+)> 
: lATTLIST fixed 
% common. attrib; 



< lELEMENT implied (n 
< lATTLIST implied 
n.attrib; 
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:! ELEMENT required EMPTY> 
:!ATTLIST required 
i.attrib; 



:!ELEMENT code . list { code . list . name , specification, (name, meaning)+); 
:!ATTLIST code. list 
attrib; 



:! ELEMENT code . list . name { %multilingual; ) *> 
:!ATTLIST code. list. name 
I.attrib; 



<!ELEMENT specification ( %multilingual; ) * 
<!ATTLIST specification 
..attrib; 



{00058300.DOC ) 



<!-- servdesc.dtd Version: 0.5 — > 
<! — Purpose: describe service — > 
<! — Terry Allen 8 Nov 1997 — > 
<!— Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common; 

<! ENTITY % countrys SYSTEM "countrys .mod"> 
%countrys; 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % addresso SYSTEM "addresso .mod"> 
%addresso; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 

<! ENTITY % servprim SYSTEM "servprim.mod"> 
%servprim; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<! ELEMENT service . description (meta?, servi 
<!ATTLIST service. list 
%common. attrib; 
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<! — servmeta.dtd Version: 0.5 — > 

<! — Purpose: describe a server's metainf ormation about a document — > 
<!-- Terry Allen 8 Nov 1997 — > 
<!— Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common, • 

<! ENTITY % ttl SYSTEM "ttlattri .mod"> 
%ttl; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 

<! ENTITY % datetime SYSTEM "datetime .mod"> 
%datetime; 

<! ENTITY % meta SYSTEM "meta.mod"> 
%meta; 

<!ELEMENT server .metadata (description?, urn?, url?, version?, time . created? 

time. last. modified?, altrep*)> 
<!ATTLIST server. metadata 

%common.attrib; 
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<! — shopcart . dtd Version: 0.5 — > 
<! — Purpose: describe a shopping cart 
<! — Terry Allen 9 Nov 1997 — > 
<!— Copyright 1997 CNgroup, Inc. --> 

SYSTEM "commatts.mod"> 



<! ENTITY % ttl SYSTEM "ttlattri .mod"; 
%ttl; 



<!ENTITY % currency SYSTEM "currency .mod"> 

<! ENTITY % proddesc SYSTEM "proddesc .mod"> 
%proddesc; 

<! ENTITY % price SYSTEM "price .mod"> 
%price; 

<! ENTITY % countrys SYSTEM "countrys .mod"> 
%countrys; 

<! ENTITY % payment SYSTEM "paymento .mod"> 
%payment; 

<! ENTITY % shipment SYSTEM "shipment .mod"> 
% shipment; 



<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers ; 

<! ENTITY % meta SYSTEM "meta.mod"> 



<! ELEMENT shopping . cart (meta?, session. id, 

market .participant . info .pointer, item. selected*, 

total. discount?, total . adjustment?, grand. total. price?) > 

<!ATTLIST shopping. cart 
% common. attrib; 
%ttl.attrib; 



<! ELEMENT session. id ( %multilingual; ) *> 
<!ATTLIST session. id 

%common. attrib; 

%party. attrib; 



<!ELEMENT item. selected {short. product. description, 
vendor .name?, quantity . desired, price. group. 
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item. subtotal? ) > 
:!ATTLIST item. selected 
% common. attrib, • 
%ttl.attrib; 



<! ELEMENT vendor 
<!ATTLIST vendor 
% common. attri] 



:! ELEMENT quantity . desired (#PCDATA)> 
MATTLIST quantity. desired 
n. attrib ; 
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<! — taxonomy . dtd Version: 0.7.2 — > 
<! — Purpose: define taxonomy structure -- 
<! — Terry Allen 4 Dec 1997 — > 
<!— Copyright 1997 CNgroup, Inc. — > 

<! ENTITY % common SYSTEM "commatts .mod"> 
% common ; 

<! ENTITY % pointers SYSTEM "pointers .mod"> 
%pointers; 

<! ELEMENT taxon (taxon.name, taxon.urn, 

taxon . info ? , taxon . parent . pointer* , 
(taxon. child. pointer | taxon) *)> 
<!ATTLIST taxon 
%coitimon.attrib; 



<! ELEMENT taxon.name ( %multilingual; ) *> 
<!ATTLIST taxon.name 
%common. attrib,■ 



<!ELEMENT taxon.urn {# PCDATA )> 
<!ATTLIST taxon.urn 
% common . attr ib ; 



<! ELEMENT taxon. info (%multilingual; ) *> 
<!ATTLIST taxon. info 
%common. attrib; 
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<!— transact. mod Version: 0.6 --> 

<! — Purpose; describe a transaction — > 

<!— Terry Allen 25 Nov 1997 — > 

<! — Copyright 1997 CNgroup, Inc. — > 



<! ELEMENT transaction . set (transaction. set+ | transactiont) > 
<!ATTLIST transaction. set 

% common . attrib ; 

%ttl.attrib; 



<!ELEMENT transaction (transaction. id+, tpa. pointer*, 

(market. participant. info. pointer | personal . info . pointer ) +, 
exchange . description, exchange . description, 
exchange . description* ) > 

<!ATTLIST transaction 
%common. attrib ,• 
%ttl.attrib; 



<!ELEMENT exchange . description ( (commerce . item, 
shipment . coordinates . set? , payment .method? ) +) > 

<!ATTLIST exchange .description 
from. party CDATA #REQUIRED 
to. party CDATA #REQUIRED 



<! ELEMENT commerce . item (( 

(retail . catalogue . item. ordered, info . description. set? ) 

I monetary .payment) , 

total .discount?, total . adjustment?, 

grand. total. price?, shipto . address? , billto . address? ) > 
<!ATTLIST commerce . item 
%common. attrib ; 



<! ELEMENT transaction 
<!ATTLIST transaction 

%common. attrib ; 

%party. attrib; 



<! ELEMENT tpa. pointer { %xll . or . urn; ) > 
<!ATTLIST tpa. pointer 

% common. attrib; 

%xll . exlink . attrib ; 

cblpointer CDATA #FIXED "content" 



< ! ELEMENT retail . catalogue . item. ordered ( catalogue . entry . pointer , 

sku?, quantity. ordered, price . group? ) > 
<!ATTLIST retail. catalogue. item. ordered 

% common. attrib; 

%ttl. attrib; 



.id {%multilingual; ) *> 
.id 
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<! ELEMENT quantity . ordered {#PCDATA)> 
<!ATTLIST quantity. ordered 
%common . attrib ; 
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